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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 8 Why requirements analysis? Early software engineering studies tried to identify the sources of problems and errors in large software development projects After Demarco
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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?
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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.
Janice Regan, 2008-2014 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?
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 16 Overview of Requirements Analysis Requirements Specification Analysis Model Requirements Elicitation Analysis System Design Functional model (requirements, use cases) Non-Functional requirements Dynamic model Static Model Analysis object model
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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.
Janice Regan, 2008-2014 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?
Janice Regan, 2008-2014 22 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) Requirements Analysis Activities
Janice Regan, 2008-2014 23 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) Requirements Analysis Activities:3