CMPT 275 Software Engineering

1

CMPT 275Software Engineering

Requirements Analysis Process

Janice Regan, 2008-2014

Janice Regan, 2008-2014 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


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


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


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


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


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


Why requirements analysis? Early software engineering studies tried to

identify the sources of problems and errors in large software development projects

Source of Errors/Problems

design27%

other10%

Requirements56%

coding7%

Effort to fix problems

other4%

coding1%

design13%

Requirements82%

After Demarco


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 dependente.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


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?


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


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


Requirements

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


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?


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


Overview of Requirements AnalysisRequirementsSpecification

Analysis Model

RequirementsElicitation

Analysis

System Design

Functional model(requirements, use cases)

Non-Functional requirements

Dynamic model

Static ModelAnalysis object model


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


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


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


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.


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?


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


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

CMPT 275 Software Engineering

Documents

software requirements

set of requirements

requirements analysis

software system

demarcojanice regan

software developers

correctjanice regan

maintainabilityjanice