Software engineering and requirement analysis.pptx

Requirements elicitation is the process of gathering and defining the requirements for a software system. The goal of requirements elicitation is to ensure that the software development process is based on a clear and comprehensive understanding of the customer needs and requirements. Requirements elicitation involves the identification, collection, analysis, and refinement of the requirements for a software system.

1. Chapter 2 Requirement Analysis and Modelling

2. Introduction Requirements elicitation is the process of gathering and defining the requirements for a software system. The goal of requirements elicitation is to ensure that the software development process is based on a clear and comprehensive understanding of the customer needs and requirements. Requirements elicitation involves the identification, collection, analysis, and refinement of the requirements for a software system. It is a critical part of the software development life cycle and is typically performed at the beginning of the project. Requirements elicitation involves stakeholders from different areas of the organization, including business owners, end-users, and technical experts. The output of the requirements elicitation process is a set of clear, concise, and well-defined requirements that serve as the basis for the design and development of the software system.

3. Requirements elicitation is perhaps the most difficult, most error-prone and most communication intensive software development. It can be successful only through an effective customer-developer partnership. It is needed to know what the users really need. Requirements elicitation Activities: Requirements elicitation includes the subsequent activities. Few of them are listed below – Knowledge of the overall area where the systems is applied. The details of the precise customer problem where the system are going to be applied must be understood. Interaction of system with external requirements. Detailed investigation of user needs. Define the constraints for system development.

4. Requirements elicitation Methods: There are a number of requirements elicitation methods. Few of them are listed below – Interviews Brainstorming Sessions Facilitated Application Specification Technique (FAST) Quality Function Deployment (QFD) Use Case Approach The success of an elicitation technique used depends on the maturity of the analyst, developers, users, and the customer involved.

5. Interviews: Objective of conducting an interview is to understand the customer’s expectations from the software. It is impossible to interview every stakeholder hence representatives from groups are selected based on their expertise and credibility. Interviews maybe be open-ended or structured. In open-ended interviews there is no pre-set agenda. Context free questions may be asked to understand the problem. In structured interview, agenda of fairly open questions is prepared. Sometimes a proper questionnaire is designed for the interview.

6. 2. Brainstorming Sessions: It is a group technique It is intended to generate lots of new ideas hence providing a platform to share views A highly trained facilitator is required to handle group bias and group conflicts. Every idea is documented so that everyone can see it. Finally, a document is prepared which consists of the list of requirements and their priority if possible.

7. 3. Facilitated Application Specification Technique: It’s objective is to bridge the expectation gap – difference between what the developers think they are supposed to build and what customers think they are going to get. A team oriented approach is developed for requirements gathering. Each attendee is asked to make a list of objects that are- Part of the environment that surrounds the system Produced by the system Used by the system Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a draft of specifications is written down using all the inputs from the meeting.

8. 4. Quality Function Deployment: In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements which are valuable to the customer. 3 types of requirements are identified – Normal requirements – In this the objective and goals of the proposed software are discussed with the customer. Example – normal requirements for a result management system may be entry of marks, calculation of results, etc Expected requirements – These requirements are so obvious that the customer need not explicitly state them. Example – protection from unauthorized access. Exciting requirements – It includes features that are beyond customer’s expectations and prove to be very satisfying when present. Example – when unauthorized access is detected, it should backup and shutdown all processes.

9. The major steps involved in this procedure are – Identify all the stakeholders, eg. Users, developers, customers etc List out all requirements from customer. A value indicating degree of importance is assigned to each requirement. In the end the final list of requirements is categorized as – It is possible to achieve It should be deferred and the reason for it It is impossible to achieve and should be dropped off

10. 4. Use Case Approach: This technique combines text and pictures to provide a better understanding of the requirements. The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional view of the system. The components of the use case design includes three major things – Actor, Use cases, use case diagram. Actor – It is the external agent that lies outside the system but interacts with it in some way. An actor maybe a person, machine etc. It is represented as a stick figure. Actors can be primary actors or secondary actors. Primary actors – It requires assistance from the system to achieve a goal. Secondary actor – It is an actor from which the system needs assistance.

11. 2. Use cases – They describe the sequence of interactions between actors and the system. They capture who(actors) do what(interaction) with the system. A complete set of use cases specifies all possible ways to use the system. 3. Use case diagram – A use case diagram graphically represents what happens when an actor interacts with a system. It captures the functional aspect of the system. A stick figure is used to represent an actor. An oval is used to represent a use case. A line is used to represent a relationship between an actor and a use case.

12. Software Requirement Specification (SRS) The production of the requirements stage of the software development process is Software Requirements Specifications (SRS) (also called a requirements document ). This report lays a foundation for software engineering activities and is constructing when entire requirements are elicited and analyzed. SRS is a formal report, which acts as a representation of software that enables the customers to review whether it (SRS) is according to their requirements. Also, it comprises user requirements for a system as well as detailed specifications of the system requirements. The SRS is a specification for a specific software product, program, or set of applications that perform particular functions in a specific environment. It serves several goals depending on who is writing it. First, the SRS could be written by the client of a system. Second, the SRS could be written by a developer of the system. The two methods create entirely various situations and establish different purposes for the document altogether. The first case, SRS, is used to define the needs and expectation of the users. The second case, SRS, is written for various purposes and serves as a contract document between customer and developer.

13. Quality characteristics of a good Software Requirements Specification (SRS) Quality characteristics of a good Software Requirements Specification (SRS) document include: Complete: The SRS should include all the requirements for the software system, including both functional and non-functional requirements. Consistent: The SRS should be consistent in its use of terminology and formatting, and should be free of contradictions. Unambiguous: The SRS should be clear and specific, and should avoid using vague or imprecise language. Traceable: The SRS should be traceable to other documents and artifacts, such as use cases and user stories, to ensure that all requirements are being met. Verifiable: The SRS should be verifiable, which means that the requirements can be tested and validated to ensure that they are being met.

14. Quality characteristics of a good Software Requirements Specification (SRS) Modifiable: The SRS should be modifiable, so that it can be updated and changed as the software development process progresses. Prioritized: The SRS should prioritize requirements, so that the most important requirements are addressed first. Testable: The SRS should be written in a way that allows the requirements to be tested and validated. High-level and low-level: The SRS should provide both high-level requirements (such as overall system objectives) and low-level requirements (such as detailed functional requirements).

15. Quality characteristics of a good Software Requirements Specification (SRS) Relevant: The SRS should be relevant to the software system that is being developed, and should not include unnecessary or irrelevant information. Human-readable: The SRS should be written in a way that is easy for non-technical stakeholders to understand and review. Aligned with business goals: The SRS should be aligned with the overall business goals and objectives of the organization, so that the software system meets the needs of the business. Agile methodologies: Agile methodologies, such as Scrum and Kanban, provide an iterative approach to requirements capturing and validation, where requirements are captured and validated in small chunks of functionality and feedback is gathered from the customer. By keeping these quality characteristics in mind, developers and stakeholders can ensure that the SRS document is clear, complete, and accurate, which in turn can help to ensure that the final software system meets the needs of the business and its users.

16. Software Requirement Specification (SRS) Format points which can be used and should be considered to form a structure of good SRS. These are as follows : 1. Introduction (i) Purpose of this document (ii) Scope of this document (iii) Overview 2. General description 3. Functional Requirements 4. Interface Requirements 5. Performance Requirements 6. Design Constraints . Non-Functional Attributes 8. Preliminary Schedule and Budget 9. Appendices

17. Software Requirement Specification (SRS) Format Introduction : (i) Purpose of this Document – At first, main aim of why this document is necessary and what’s purpose of document is explained and described. (ii) Scope of this document – In this, overall working and main objective of document and what value it will provide to customer is described and explained. It also includes a description of development cost and time required. (iii) Overview – In this, description of product is explained. It’s simply summary or overall review of product. General description : In this, general functions of product which includes objective of user, a user characteristic, features, benefits, about why its importance is mentioned. It also describes features of user community.

18. Software Requirement Specification (SRS) Format Functional Requirements : In this, possible outcome of software system which includes effects due to operation of program is fully explained. All functional requirements which may include calculations, data processing, etc. are placed in a ranked order. Interface Requirements : In this, software interfaces which mean how software program communicates with each other or users either in form of any language, code, or message are fully described and explained. Examples can be shared memory, data streams, etc. Performance Requirements : In this, how a software system performs desired functions under specific condition is explained. It also explains required time, required memory, maximum error rate, etc. Design Constraints : In this, constraints which simply means limitation or restriction are specified and explained for design team. Examples may include use of a particular algorithm, hardware and software limitations, etc.

19. Software Requirement Specification (SRS) Format Non-Functional Attributes : In this, non-functional attributes are explained that are required by software system for better performance. An example may include Security, Portability, Reliability, Reusability, Application compatibility, Data integrity, Scalability capacity, etc. Preliminary Schedule and Budget : In this, initial version and budget of project plan are explained which include overall time duration required and overall cost required for development of project. Appendices : In this, additional information like references from where information is gathered, definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.

20. Use case In software and systems engineering, a use case is a list of actions or event steps, typically defining the interactions between a role (known in the Unified Modeling Language as an actor ) and a system, to achieve a goal. The actor can be a human, an external system, or time. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. Another way to look at it is a use case describes a way in which a real-world actor interacts with the system. In a system use case you include high-level implementation decisions. System use cases can be written in both an informal manner and a formal manner. ( Wiki )

21. What is the importance of Use Cases? Use cases have been used extensively over the past few decades. The advantages of Use cases includes: The list of goal names provides the shortest summary of what the system will offer It gives an overview of the roles of each and every component in the system. It will help us in defining the role of users, administrators etc. It helps us in extensively defining the user’s need and exploring it as to how it will work. It provides solutions and answers to many questions that might pop up if we start a project unplanned.

22. How to plan use case? Use Case: What is the main objective of this use case. For eg. Adding a software component, adding certain functionality etc. Primary Actor: Who will have the access to this use case. In the above examples, administrators will have the access. Scope: Scope of the use case Level: At what level the implementation of the use case be. Flow: What will be the flow of the functionality that needs to be there. More precisely, the work flow of the use case.

23. Generally, the use-cases diagram is used for: Examining the system's requirements. Capturing the system's Functionalities. We use use-case diagram in order to modeling the general idea behind the system. System's Forward and reverse engineering using several test cases. Complex visual designing of software.

24. Basic Use-Case Diagram Symbols and Notations There are following use-case diagram symbols and notations: System With the help of the rectangle, we can draw the boundaries of the system, which includes use-cases. We need to put the actors outside the system's boundaries.

25. Use-Case With the help of the Ovals, we can draw the use-cases. With the verb we have to label the ovals in order to represent the functions of the system.

26. Actors Actors mean the system's users. If one system is the actor of the other system, then with the actor stereotype, we have to tag the actor system.

27. To write a use case, follow the steps given below: Identify the system’s actors and start with one of the actors, for example, the customer of an e-commerce website. Define what the customer wants to use the system for. For example, browsing information or online shopping. All these actions will become the use cases. For each use case, describe the normal and alternate flow of events. The flow of events should include the customer’s actions and the system’s responses to them. Repeat the steps for all the actors of the system.

28. Use Case ID 1 Use Case Name View Orders Actors Admin Description The admin will be able to view all the orders placed by the customer. Normal Flow The admin will log in. The admin will select the 'View Orders' option. The admin will be prompted to select any filters (date or time). The admin will select the filters. The system will display the relevant orders on the screen. Alternate Flow None

29. Requirements Modeling Requirements modeling is comparable to the planning stage of a project, where a software program must be updated or created from scratch. Learn how to identify the requirements, and the patterns, functions, classes, and behaviors. Requirements modeling in software engineering is essentially the planning stage of a software application or system. Generally, the process will begin when a business or an entity (for example, an educational institution) approaches a software development team to create an application or system from scratch or update an existing one. Requirements modeling comprises several stages, or 'patterns': scenario-based modeling, data modeling, flow-oriented modeling, class-based modeling and behavioral modeling. Each of these stages/patterns examines the same problem from a different perspective.

30. Identifying Requirements Requirements in this context are the conditions that a proposed solution or application must meet in order to solve the business problem. Identifying requirements is not an exclusively technical process, and initially involves all the stakeholders, like the representatives of the entity that has commissioned the software project, who may not necessarily be from a technical background, as well as the software developers, who are not necessarily the technical team. Together, they discuss and brainstorm about the problem, and decide what functions the proposed application or system must perform in order to solve it.

31. Identifying Requirements Functional vs. Non-Functional Requirements A functional requirement specifies something that the application or system should do. Often, this is defined as a behavior of the system that takes input and provides output. For example, a traveler fills out a form in an airline's mobile application with his/her name and passport details (input), submits the form, and the application generates a boarding pass with the traveler's details (output). Non-functional requirements, sometimes also called quality requirements, describe how the system should be, as opposed to what it should do. Non-functional requirements of a system include performance (e.g., response time), maintainability and scalability, among many others. In the airline application example, the requirement that the application must display the boarding pass after a maximum of five seconds from the time the traveler presses the 'submit' button would be a non-functional requireme nt.

32. Working with Requirements Modeling Requirements modeling includes several stages, or patterns, each examining the problem and its proposed solution from a different perspective. Technically, there is no 'right way' of going through these stages, but generally, the process would begin with scenario-based modeling and complete with behavioral modeling.

33. Scenario-based Modeling Scenario-based modeling's primary objective is to look at a system from the user's perspective and produce a use case, an example instance of the user interacting with the system, like the traveler using the airline application to generate their boarding pass. It makes sense to start with this step as the other requirements modeling stages/patterns will make reference to this use case. Below is a use case diagram depicting three possible use cases of the traveler using the airline application. The first is the one in the example, getting a boarding pass. The following two are searching for flights and buying air tickets.

34. Class-based Modeling Class-based modeling identifies classes, attributes and relationships that the system will use. In the airline application example, the traveler/user and the boarding pass represent classes. The traveler's first and last name and travel document type represent attributes, characteristics that describe the traveler class. The relationship between traveler and boarding pass classes is that the traveler must enter these details into the application in order to get the boarding pass and that the boarding pass contains this information along with other details, like the flight departure gate, seat number, etc. Data Modeling Data modeling essentially works with the same elements as class-based modeling (object, attributes, relationships), but uses the information to produce a detailed model, termed a physical model, of what the database structure will be that will hold all the data; for example, the name, passport number and other details of the travelers that use the airline application.

35. Behavioral Model : Effect of behavior of computer-based system can be seen on design that is chosen and implementation approach that is applied. Modeling elements that depict behavior must be provided by requirements model. Method for representing behavior of a system by depicting its states and events that cause system to change state is state diagram. A state is an externally observable mode of behavior. In addition, state diagram indicates actions taken as a consequence of a particular event.

36. Flow-oriented elements As it flows through a computer-based system information is transformed. System accepts input, applies functions to transform it, and produces output in a various forms. Input may be a control signal transmitted by a transducer, a series of numbers typed by human operator, a packet of information transmitted on a network link, or a voluminous data file retrieved from secondary storage. Transform may compromise a single logical comparison, a complex numerical algorithm, or a rule-inference approach of an expert system. Output produce a 200-page report or may light a single LED. In effect, we can create a flow model for any computer-based system, regardless of size and complexity.