Software Requirements Engineering: Understanding and Analysis Process

1. Chapter 7 CS 8532: Advanced Software Engineering Dr. Hisham Haddad • Class • will • start • momentarily. • Please Stand By …

2. Requirements Engineering Elements of software requirements gathering Chapter 7

3. What is Software Requirement? “A software requirement is a description of the principle features of a software product, its information flow, its behavior, its attributes. In sum, a software requirement provides a blueprint for the development of a software product. The degree of understandability, accuracy, and rigor of the description provided by a software requirement document tends to be directly proportional to the degree of quality of the derived product.” Source: Software Engineering: An Engineering Approach, by James Peters and Witold Predrycz, Wiley, 2000, Page 118.

4. Requirements Engineering Goal: Better understanding of the problem at hand and business impact of the system. How is it done? Through a process that facilitates a set of defined tasks. Why do it? To establish a solid foundation for system design and construction. It is not the solution, but an approach to facilitate the development of a effective solution.

5. What is Software Requirements Analysis? - 1 Software requirements analysis is process of understandingcustomer requirements of the software system to be built, and buildinganalysis model of the system (data, functions, behaviour/control flow, interfaces). The analysis model serves as - basis for creating specifications and software design - means for assessing the quality of the system to be built This process requires active participation of the customer, and it is crucial step in the development process. The analyst may play different roles - interrogator, advisor, problem solver, and negotiator.

6. What is Software Requirements Analysis? - 2 The outcome of the process: - Software Requirements Specifications (SRS). The SRS should be clear, complete, and consistent with customer needs. - Quality Assurance Plane - set of activities that the project team can follow to ensure software quality throughout the product life cycle (portability, reliability, efficiency, V&V criteria, cost, acceptance criteria, etc…)

7. System vs. Software Requirements System requirements analysis, in part, focus on how the software element interacts with other elements of the system (constraints and limitations). Software requirements analysis focus on the data, functional, and behavioural modeling of the software itself (OOA focuses on classes, relations, and object behaviour modeling). For software requirements analysis, try to fully answer the following: - What are the inputs and outputs? - What functions should be defined? - What behaviors (control activities) should be exhibited? - What interfaces are needed?

8. Why Do Requirements Analysis? - Identify the customer and work together to negotiate product-level requirements - Build an analysis model (focus on data, define functions, represent behaviour) - Prototype areas of uncertainty in the system - Develop a specification to guide the design and development - Conduct formal technical reviews to ensure software quality

9. build a prototype requirements elicitation develop Specification the problem Review create analysis models The Analysis Process

10. Problem Analysis Environment Products Functions Operations • - People (operators and users) • - Devices • Other items affected by the system • business value - Inputs - Outputs - Items produced for the system - People functions - Device functions - Other functions needed to produce services and items - Methods used - operations used to produced items - When operations occur Problem Analysis

11. Real Problems… - the customer has only a vague idea of what is required. - the software engineer (analyst) is willing to proceed with the vague idea on the assumption that we'll fill in the details as we go. - the customer keeps changing requirements. - the software engineer (analyst) is affected by these changes, making errors in the specifications. • Others?

12. Requirements Engineering Work Tasks - 1 • Inception: Starting the project… where to star? Ask a set of questions that establish - basic understanding of the problem - the people who want a solution - the nature of the solution that is desired, and - the effectiveness of initial communication and collaboration between the customer and the developer • Elicitation: Elicit requirements from all stakeholders • Elaboration: Modeling and refinement (chapter 8) - create analysis model that identifies data, function and behavioral requirements. (in OOA, analysis classes, their services, their relationships). • Negotiation: Agree on a deliverable system that is realistic for developers and customers.

13. Requirement Engineering Work Tasks - 2 • Specification: Can be any one (or more) of the following: • A written document • A set of models • A formal mathematical • A collection of user scenarios (use-cases) • A prototype • Validation: A review mechanism that looks for • errors in content or interpretation • areas where clarification may be required • missing information • inconsistencies (a major problem with large systems) • conflicting or unrealistic (unachievable) requirements • Conformity issues (with standards set for the product, process, project)

14. Requirement Engineering Work Tasks - 3 • Requirements management: A process to identify, control, and track changes to requirements (similar to SCM) Traceability tables facilitate requirements management • feature (of system) traceability table (see figure 7.1, page 148) • source (of requirements) traceability table • dependency (among requirements) traceability table • subsystem traceability table (categorization of requirements) • interface traceability table

15. Inception • Identify stakeholders • “who else do you think I should talk to?” • Recognize multiple points of view • Work toward collaboration (productive meetings) • The first questions to ask: • Who is behind the request for this work? • Who will use the solution? • What will be the economic benefit of a successful solution? • Is there another source for the solution that you need? • … (see page 152)

16. Elicitation - 1 Initial interview: - break the ice and establish communications channels - scripted (context-free) questions may be used • understand customer goals and scope the problem • identify stakeholders interested in the system Sample questions: - What do you expect of the new system? - How will the system help your organization? - Who will be using the system? - Will the system interact with other systems? - etc…

17. Elicitation - 2 There is not one way for gathering requirements from the client… The meeting format determines its effectiveness and outcomes. It is important to listen, but that is not enough! In addition to meeting notes, recording the meetings may be required. One approach is called Facilitated Application Specification Techniques(FAST) . It is a team-oriented approach to promote constructive and effective communications.

18. FAST Approach Guidelines: • participants must attend entire meeting • all participants are equal • preparation is as important as meeting • all pre-meeting documents are to be viewed as proposed • off-site meeting location is preferred • set an agenda and maintain it • focus on requirements and don’t get mired in technical details Benefits: many points of view, instantaneous discussion and refinement, concrete step toward developing specs.

19. Collaborative Approach Guidelines: • Meetings are conducted and attended by both software engineers and customers • Rules for preparation and participation are established • An agenda is suggested • A "facilitator" (can be a customer, a developer, or an outsider) controls the meeting • A "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used • The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements

20. Quality Function Deployment (QFD) - 1 Another approach for requirements gathering. Its purpose is to maximize customer satisfaction while developing software requirements that are valuableto the customer. It identifies three types of requirements: - Normal requirements: what the customer explicitly states and wants in the system. - Expected requirements: what the customer wants but did not explicitly state assuming we know such requirements. - Exciting requirements: additional features we can offer.

21. Quality Function Deployment (QFD) - 2 QFD meeting aspects (deliverables/outcomes): - Function deployment: determines the “value” (as perceived by the customer) of each function required of the system. - Information deployment: identifies data objects and control events of the system (based on required functions). - Task deployment: illustrate system behavior in the target environment. Value analysis activity determines the priority of system requirements identified in the above deliverables. Check QFD Institute at http://www.qfdi.org/

22. Elicitation Work Products • a statement of need and feasibility (or statement of work). • a bounded statement of scope for the system or product. • a list of customers, users, and other stakeholders who participated in requirements elicitation. • a description of the system’s technical environment. • a list of requirements (preferably organized by function) and the domain constraints that apply to each. • a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. • any prototypesdeveloped to better define requirements.

23. Use-Cases - 1 Another approach to requirement gathering is Use-cases. Use case are scenarios of system usage by different actors (classes of users and devices). e.g., student, faculty, and registrar are actors for student registration system. - Uses-cases are used to: - obtain requirements from the customer - effectively express requirements to the customer Annotated diagrams are common way to present use-cases.

24. Use-Cases - 2 Some of the questions a use-case should answer: - What are the main functions performed by the actor? - What information will the actor acquire, produce or change? - What information does the actor desire of the system? - others… Check the article “Structuring Use Cases with Goals” at: http://alistair.cockburn.us/ Structuring+use+ cases+with+goals See example page 161. Retrieve a file use-case 1. User clicks file menus 2. System displays options new and open 3. User clicks option open 4. System displays open file window 5. User enters/selects file name 6. User clicks open button 7. System retrieves and opens the file

25. Analysis Principles - 1 Analysis methods may vary, but they share common principles: 1. Information Domain Analysis and Data modeling: - define data (and control) items/objects - describe data attributes - establish data relationships and data structures e.g., student transcript (data object) with different attributes. 2. Function modeling: (iterative process) - identify functions that transform data objects - indicate how data flow through the system - represent producers and consumers of data objects

26. Analysis Principles - 2 3. Behaviour modeling: - indicate different states of the system - specify events that cause the system to change state 4. Partitioning the model: refine each sub-model to represent lower levels of abstraction - refine data objects - create a functional hierarchy - represent behavior at different levels of details 5. The essence: focus on the problem (requirements) not the implementation details (i.e., answer “what” questions).

27. SRS Structure Table of Contents 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements (next box)4. Requirement traceability Appendices Index 3. Specific requirements 3.1 Interface requirements 3.2 Functional requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements For SRS details and other templates, check author’s site athttp://www.rspa.com/docs/index.html From DoD SRS Standard DI-MCCR-80025A

28. Building Analysis Model Elements of the analysis model: (more in Chapter 8) - Scenario-based elements • Functional: Processing narratives for software functions • Use-case: Descriptions of the interaction between an “actor” and the system - Class-based elements • Implied by scenarios - Behavioral elements (depict system behavior) • State transition diagram - Flow-oriented elements • Data flow diagram SRS Templates and “SRS Components” document will be posted on the Project Page.

29. Negotiate Requirements • Identify the key stakeholders • These are the people who will be involved in the negotiation • Determine each of the stakeholders “win conditions” • Win conditions are not always obvious • Negotiate • Work toward a set of requirements that lead to “win-win” deal

30. Validate Requirements - 1 • Is each requirement consistent with the overall objective for the system/product? • Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? • Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? • Is each requirement bounded and unambiguous? • Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? • Do any requirement conflict with other requirements?

31. Validate Requirements – 2 • Is each requirement achievable in the technical environment that will house the system or product? • Is each requirement testable, once implemented? • Does the requirements model properly reflect the information, function and behavior of the system to be built? • Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system? • Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?

32. Deployment Practices • Deployment involves system delivery, end-user support, and feedback from end-users. • Principles: • Manage customer expectations for each increment • A complete delivery package should be assembled and tested • A support group should be established before delivery • Instructional materials must be provided to end-users • Buggy software should be fixed first, delivered later • Encourage and collect customer feedback on the system

33. Suggested Problems Consider working the following problems from the end of chapter 7, page 173, for practice purpose: 7.1, 7.2, 7.3, 7.4, 7.11, 7.13, 7.16, 7.17 No submission is required. Think about these problems and work them for yourself!

34. Last Slide End of Chapter 7