CMPT 275 Software Engineering

1. CMPT 275Software Engineering Requirements Analysis Process

2. Requirements Analysis • A requirement is a feature (ability) of the system that client requires • Requirements analysis seeks to assess (analyze) and specify the behavior of the final system as a set of requirements. • Requirements analysis results in a complete, consistent, correct, and unambiguous specification of the requirements • Requirements analysis can be iteratively carried out or done in a top-down fashion

3. Definitions • Complete: All features of interest to the client are described by the requirements • Consistent: No requirement contradicts any other requirement in the specification • Unambiguous: The requirements cannot be interpreted in multiple ways. • Correct: The requirements describe all features of interest to the client, but not extra or superfluous features

4. Activities: Requirements Analysis • Requirements Gathering (Elicitation) • Understand what the product must do, what the requirements of the product are • Requirements Specification • Enumerate (list) each function the product must do and the constraints under which the function must be done • Requirements Analysis • Analyze the requirements of the system and verify that the list is complete, unambiguous, consistent and correct

5. Purpose of Requirements Analysis • Requirements analysis is used by software developers to understand • The functions of the application to be developed • What the client/user expects the application to do • The relative importance of each function of the system to the client/user • Necessary details of the application domain • The scope of the project

6. Purpose of Requirements Analysis • Requirements Analysis also helps the clients/users to understand / quantify • What their own requirements are • Which requirements are most important • The feasibility and costs of some features that may be difficult to implement (this may change the user’s prioritization of features) • How they will be able to complete their required tasks

7. Importance of Requirements Analysis • Frederick Brooks: “The hardest single part of building a software system is deciding precisely what to build” • Barry Boehm: by investing more up-front effort in verifying and validating the software requirements, software developers will see reduced integration and test costs, as well as higher software reliability and maintainability

8. Why requirements analysis? • Early software engineering studies tried to identify the sources of problems and errors in large software development projects After Demarco

9. Types of Requirements • Functional Requirements: • Specify services that the software system must provide. • Describe all interactions between the system and it’s environment that are not implementation dependent e.g.: Compute value of user’s stock portfolio • Non-Functional Requirements: • Specify quality(usability, reliability, performance, …) • Specify constraints (budget, legal, implementation, …) e.g.: Compute value of stock portfolio in < 1s

10. Non-Functional Requirements • Quality: Performance • response time, capacity, availability, throughput • Quality: Usability • Ease of use • Amount / detail of user documentation • Specified fonts, layouts, colours, logos • Special client interface needs?

11. Non-Functional Requirements • Quality: Dependability, Reliability • Acceptable rate of errors, mean time to failure • Robustness: ability to deal with incorrect inputs and high stress operating conditions without serious failures • Quality: Supportability • maintainability: can easily fix defects or deal with new technology • Adaptability: ease of adding new features • Portability

12. Non-Functional Requirements • Constraints: Implementation • Must use specific languages, tools, platforms … • Constraints: Legal requirements • Licensing, government regulation, certification • Constraints: Operations requirements • Administration and management • Constraints: Interface requirements • Interchange formats, interface to other systems • Constraints: Packaging requirements

13. Requirements • It is IMPORTANT to understand that requirements originate from the needs of the client, not from the wishes of the application design team.

14. Requirements • Common errors of developer driven requirements • Replacing the ‘requirements’ requested by the user to their own vision of the application • Deciding to use a particular tool not supported by the user because it would make the application ‘better’ For example producing a UNIX tool when developing an application for a company that uses only WINDOWS • Can you think of others?

15. Realistic, Verifiable, Traceable • Requirements are only useful if they have the following properties • Realism: system can be implemented without violating any constraints • Verifiability: As the system is designed and built repeatable tests can be developed that demonstrate the system fulfills each requirement • Traceability: Each requirement can be mapped to one or more system functions, each system function can be mapped to at least one requirement. Interdependence between requirements are also mapped

16. Overview of Requirements Analysis Requirements Specification Requirements Elicitation Functional model (requirements, use cases) Analysis Non-Functional requirements Analysis Model System Design Dynamic model Static Model Analysis object model

17. Requirements Analysis Phase • Informal scenarios -> questions to client • Software Requirement Specification doc (SRS) • Use cases • System Context diagram • Primary classes • Scenarios (not “informal scenarios”) • Use case diagram • Class diagram

18. Requirements Gathering Activities • Develop informal scenarios based on the project description • Informal scenarios are used to • Understand the initial project • Formulate questions for client meetings, interviews, site visits … • Clarify understanding of the system requirements

19. Gathering Requirements • Interviews with client, managers, etc. • Clarify project description, informal scenarios can help • May be conducted by a member or members of the development team or a Business Analyst • May include technical specialists from the clients organization as well as end users or clients … • Visit to client site, see how the application will be used • Analyze current procedures your system will replace • Analyze current electronic system if one exists

20. Requirements Specification Activity • Write a list of requirements for your project based on the understanding you have gained from informal scenarios and meetings with the clients \ users • You may need one or more cycle of meeting with the client followed by refining your informal scenarios.

21. Requirements Specification Activity • The requirements must often be prioritized • Basis of prioritization • What resources are available? • Are all users requests possible to implement with available resources? (scope is important) • Which requirements are critical to the client? • Which requirements are needed by the client? • Which requirements are desired by the client?

22. Requirements Analysis Activities • Analyze your requirements • Tools used to analyze your requirements include: • System context diagram, Class (object) diagram, Primary Classes • Use cases and use case diagrams • Scenarios (formal)

23. Requirements Analysis Activities:3 • Update your requirements based on this analysis • If necessary repeat the cycle of analysis of requirements (may also need additional elicitation) followed by update of requirements • Complete revision of your SRS (first version to go to the client) • May conduct a structured client requirements review to confirm and or refine your requirements • If necessary update of your SRS (both requirements and analysis)