Requirement Analysis

Requirements Analysis Objective: determine what the system must do to solve the problem (without describing how) Done by Analyst (also called Requirements Analyst) Produce Software Requirements Specifications (SRS) document Incorrect, incomplete, inconsistent, ambiguous SRS often cause for project failures and disputes

Challenges of Requirement Analysis Lack of stakeholder involvement Stakeholders may not know exactly what is needed Users change their mind over time Different stakeholders may have conflicting requirements Stakeholders may not be able differentiate between what is possible and cost-effective against what is impractical Analyst has no or limited domain knowledge Often client is different from the users

Cost of Delay in Fixing Requirements Errors 200 Data: Boehm & Papaccio (1988) IEEE Trans. Software Eng. 150 100 50 0 Nominal unit cost Cost to fix Reqts. definition Design Coding Unit testing Post-delivery 200-fold increase after delivery 20-fold increase during devt.

Requirement Engineering Requirements engineering is a systematic approach to elicit, organize and document the requirements in a form and manner that forms the basis for design and development of the software. Requirements engineering involves all lifecycle activities devoted to identification of user requirements, analysis of the requirements to derive additional requirements, documentation of the requirements as a specification and validation of the documented requirements against user needs, as well as processes that support these activities

What is a requirement IEEE defines a requirement as [1] A condition or capability needed by a user to solve a problem to achieve an objective. [2] A condition or a capability that must be met or possessed by a system, to satisfy a contract, standard, specification or other formally composed document.

Types of Requirements Functional Requirements Nonfunctional Requirements

Functional Requirements IEEE defines functional requirements as function that a system or a component must be able to perform Example The system should allow the students to check their marks. The system should allow the user to sort the list of available books by title.

Non-functional Requirements Non-functional requirements define the overall qualities or attributes of the resulting system. These are constraints on the services or functions offered by the system Example The response time of the home page must not exceed five seconds

Types of non-functional requirements Performance (recovery time, resource usage, throughput, response time) All webpage must download within three seconds during an average load and five seconds during a peak load Usability (human factors,aesthetics, consistency in the user interface, online and context-sensitive help, wizards,user documentation, training materials ) The end user shall be able to place an order within thirty seconds.

Types of non-functional requirements (cont..) Reliability (frequency and severity of failure, recoverability, predictability, accuracy, mean time between failure, availability) The mean time to failure shall be at least four months Security (access permission, integrity) The access permissions for system data may only be changed by the system s data administrator Supportability (adaptability, extensibility, maintainability, configurability, serviceability, portability) The system shall allow users to create new workflows without the need for additional programming.

Types of non-functional requirements (cont..) Technical requirements (related to environment, hardware or software) The system shall work on a system with 256MB memory.

Classification of non functional requirements Product Requirements Process Requirements External Requirements

Classification of non functional requirements Non-functional requirements Process requirements Delivery requirements implementation requirements standards requirements Product requirements Usability requirements Reliability requirements Safety requirements Efficiency requirements Performance requirements Capacity requirements External requirements Legal constraints Economic constraints Interoperability requirements

RE process activities Requirements elicitation Requirements analysis and negotiation Requirements specification Requirements Validation Requirements management

Requirements Elicitation Requirements Elicitation is the process of discovering the requirements for a system through consultation with stakeholders.

Prepare for Requirements Gathering Gain common agreement on the problem definition. Identify users and other stakeholders Understand the domain Identify the solution boundaries Identify the constraints to be imposed on the solution

Tools for eliciting requirements Interviews Questionnaires Focus Groups Observations Studying Documents Scenarios Prototypes

Scenario-Example Scenario: A successful withdrawal attempt at an automated teller machine (ATM). John Smith presses the Withdraw Funds button The ATM displays the preset withdrawal amounts ($20, $40, ) John chooses the option to specify the amount of the withdrawal The ATM displays an input field for the withdrawal amount John indicates that he wishes to withdraw $50 dollars The ATM displays a list of John s accounts, a checking and two savings accounts John chooses his checking account The ATM verifies that the amount may be withdrawn from his account The ATM verifies that there is at least $50 available to be disbursed from the machine The ATM debits John s account by $50 The ATM disburses $50 in cash The ATM displays the Do you wish to print a receipt options John indicates Yes The ATM prints the receipt

Requirements Analysis Analysis is refinement of stakeholder needs into formal product specification. The goal of analysis is to discover problems, incompleteness and inconsistencies in the elicited requirements. Requirements analysis involves refining, analyzing and scrutinizing the gathered requirements to make sure all stakeholders understand what they mean and to find errors, omissions or other deficiencies.

Analysis Checks Necessity Checking Does the requirement contribute to the the problem addressed Consistency checking Does the requirements contradict? Completeness checking Does any services or constraints which are needed are missed out? Feasibility Checking Is it feasible in the context of the budget and schedule?

Requirements Analysis (contd..) Issues identified are communicated back to the relevant stakeholders and resolved through negotiation Models may be created during analysis to better understand the problem to be solved Requirements are prioritized in consultation with the stakeholders

Modelling Models are created to gain a better understanding of the actual entity or object to be built During requirements analysis models of the system are built. These models focus on what the system must do, not on how it does it

Data Flow Diagram Very popular tool for describing the functions of a system in terms of processes and data used by them

Example 1 Suppose an accountant says to you When a vendor sends me an invoice, I record it in the accounts payable book and then I generate a cheque to the vendor in 30 days

DFD (contd..) DFD is a hierarchical graphical model of a system that depicts the flow of data and the transformation that it undergoes through out a system. It views the system as a function that transforms the input into desired output. A DFD depicts the transformational processes of a system, the collections (stores) of data the system manipulate and the flows of data between processes, stores and the outside world.

DFD Notation

DFD Diagramming Rules :Process No process can have only outputs or only inputs processes must have both outputs and inputs. Process labels should be verb phrases.

DFD Diagramming Rules :Data Store All flows to or from a data store must move through a process. Data store labels should be noun phrases.

DFD Diagramming Rules: Source/Sink No data moves directly between external entities without going through a process. Interactions between external entities without intervening processes are outside the system and therefore not represented in the DFD. Source and sink labels should be noun phrases. Data flow labels should be noun phrases.

Steps in creating a DFD Draw a context diagram Continue to decompose to nth level DFD to manage the complexity

Context Diagram It is the most abstract data flow representation of a system It shows the entire system under consideration as a single high-level process Identifies its external interfaces It represents the context in which the system is to exist. It is also called Level 0 DFD

Context Diagram (contd..)

Example 2 Draw the DFD for a distance education university. The enrolment process for works as follows: Students send in an application form containing their personal details, and their desired course. The university checks that the course is available. If the course is available and the student has necessary qualifications, then the student is enrolled in the course, and the university confirms the enrolment by sending a confirmation letter to the student. If the course is unavailable or if the student does not have the desired qualification, then a rejection letter is sent to the student.

Example (contd..) people/organisations/things that supply information to or use information from the system => external entities (EE) actions/doing words/verbs => Processes (P) movement/exchange of information/data between external entities to processes, and processes to processes => data flows (DF) store/record information/data => data stores(ds)

Example 2 A student (EE) sends in an application form (DF) containing their personal details, and their desired course. The university checks (P) that the course is available. If the course is available and if the student has necessary qualifications, then the student is enrolled (P) in the course, and the university confirms (P) the enrolment by sending a confirmation letter (DF) that they are registered for the course to the student. If the course is unavailable, or if the student does not have the desired qualification, then a rejection letter (DF) is sent to the student.

Context Diagram Application Form 0 Student Course Enrolment System Confirmation/ Rejection Letter

Level 1 DFD Course Details Student Application Form 1 Check Eligibility Courses Confirmation/ Rejection Letter Accepted /Rejected Selection Accepted Selection Course Enrolment details 3 Confirm Registration 2 Enrol Student Student Details Student

DFD decomposition Creating a more detailed data flow diagram for a process. Each process in the DFD is decomposed into sub-processes until elementary processes are identified. Each decomposition is a DFD itself It is an iterative process of breaking a system description down into finer and finer detail Decompose into 3 to 7 processes Decomposition of a process is also known as factoring or exploding a process Decomposition allows to organize the overall DFD in a series of levels so that each levels provides successively more detail about a portion of the level above it.

DFD decomposition (contd..)

Balancing DFDs When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decomposition The input and output data flows of a parent process must match with that of the child DFD.

An unbalanced set of data flow diagrams SOURCE A 0 B SINK (a) Context diagram SOURCE 1 A 1.0 SOURCE 2 C 2.0 B SINK (b) Level-0 diagram

An balanced set of data flow diagrams SOURCE A 0 B SINK C (a) Context diagram SOURCE 1 A 1.0 SOURCE 2 C 2.0 B SINK (b) Level-0 diagram

Examples of product requirements The System service X shall have an availability of 999/1000 or 99%. This is a reliability requirement which means that out of every 1000 requests for this service, 999 must be satisfied. System Y shall process a minimum of 8 transactions per second. This is a performance requirement. The executable code of System Z shall be limited to 512Kbytes. This is a space requirement which specifies the maximum memory size of the system. The system shall be developed for PC and Macintosh platforms. This is a portability requirement which affects the way in which the system may be designed The system must encrypt all external communications using the RSA algorithm. This is a security requirement which specifies that a specific algorithm must be used in the product

Requirements Specification Software Requirements Specification is produced at the culmination of the analysis task.

Software Requirements Specification A document that clearly and precisely describes each of the essential requirements functions, performance, design, constraints, and quality attributes) of the software and the external interfaces. Each requirement is defined in such a way that its achievement can be objectively verified by a prescribed method, for example, inspection, demonstration, analysis or test. [IEEE]

Benefits of SRS SRS document is a contract between the development team and the customer Reduce the development effort Provide a basis for estimating costs and schedules Provide a baseline for validation and verification. Facilitate transfer Serve as a basis for enhancement

Characteristics of SRS Correct Unambiguous Complete Consistent Ranked for Importance /stability Verifiable Modifiable Traceable

Correct An SRS is correct if and only if every requirement stated therein is the one that the software shall meet.

Unambiguous An SRS is unambiguous if and only if every requirement stated therein has only one interpretation Example of an ambiguous requirement All customers have the same control field. a) All customers have the same value in their control fields. b) All customers control field have the same format. c) One control field is issued for all customers.

Complete All significant requirements are included. Definition of responses of the SW to all realizable classes of input data in all situations. Conformity to a standard. Full labeling and referencing of all figures, tables etc. and definition of all terms and units of measure No sections are marked To Be Determined (TBD)

Consistent No two requirements are in conflict Conflicting terms Example Prompt is used in one requirement while cue is used by another requirement to denote a message a user input data Conflicting characteristics Example One requirement might state the format on the output report as tabular, but another as textual Temporal or logical inconsistency Example One requirement may state that A will occur before B and another requirement may state that A will occur 15 seconds after the start of system B.

Ranked for Importance /stability Each requirements in the SRS should be identified to make their differences clear and explicit

Verifiable A requirement is verifiable if and only if there exists some finite cost effective process with which a person or machine can check that the SW meets the requirement Example The product should work well ---non-verifiable The output of the program shall usually be given within10 seconds--- verifiable

Modifiable Structure and style of SRS is such that changes to requirements can be made easily, completely and consistently. SRS organization -- table of contents, index, explicit cross-referencing no redundancy

Traceable An SRS is traceable if the origin of each requirement is clear and it facilitates the referencing of each requirement in future. Backward traceability Forward traceability

Problems with an Unstructured Specification It would be very difficult to understand that document. It would be very difficult to modify that document. Conceptual integrity in that document would not be shown. The SRS document might be ambiguous and inconsistent.

Requirement Specification Format (Based on IEEE Recommendation) 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Overview

1.1 Purpose Describe the purpose of the particular SRS and its intended audience

1.2 Scope Identify the software product(s) to be produced by name. Explain what the software product(s) will, and if necessary, will not do. Describe the application of the software being specified and goals. including relevant benefits, objectives

1.3 Definitions, Acronyms and Abbreviations Provide the definitions of all terms, acronyms and abbreviations required to properly interpret the SRS

1.4 References Provide a complete list of documents referenced elsewhere in the SRS

1.5 Overview Describe what the rest of the SRS contains Explain how the SRS is organized

2. General Description 2.1 Product Perspective 2.2 Product Functions Overview: 2.3 User Characteristics: 2.4 General Constraints: 2.5 Assumptions and Dependencies

2.1 Product Perspective Put the product into perspective with other related products, defining if the product is independent or is a part of a larger product. Describes the relationship with other products and principle interfaces

2.2 Product Functions General overview of tasks; including data flow diagrams

2.3 User Characteristics Describe the general characteristics of the intended users of the product including educational level, experience and technical expertise

2.4 General Constraints About schedule, resources, cost, etc.

2.5 Assumptions and Dependencies List any factors that affect the requirements stated in the SRS

3. Specific Requirements 3.1 External Interface Requirements 3.2 Functional Requirements 3.3 Performance Requirements 3.4 Design Constraints 3.5 Software Requirement Attributes 3.6 Other Requirements

3.1 External Interface Requirements User Interfaces Hardware Interfaces Software Interfaces Communication Interfaces

3.2FUNCTIONAL REQUIREMENT 3.2.1 Introduction 3.2.2 Inputs 3.2.3 Processing 3.2.4 Outputs 3.2.. (Repeat Similarly For Each Function)

3.3 Performance Requirements Capacity requirements (no of users, no of files), response time, through-put (in measurable terms)

3.4 Design Constraints Standards Compliance Hardware Limitations

3.5 Software Requirement Attributes Reliability Availability Security Maintainability Portability

3.6 Other Requirements Possible future extensions

Appendix Glossary Analysis Models Note: All sections are not required for all projects.

Problems without an SRS Document The system would not be implemented according to customer needs. Difficult for the maintenance engineers to understand the functionality of the system. Difficult for user document writers to write the users manuals properly without understanding the SRS document.