Requirement Analysis

Transcription

1 Requirement Analysis

2 Requirements Analysis & Specification 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

3

4 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 to 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

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

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

7 Types of Requirements Functional Requirements Nonfunctional Requirements

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

9 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

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

11 Types of non-functional requirements (cont..) Reliability (frequency and severity of failure, recoverability, 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, maintainability, configurability, serviceability, portability) The system shall allow users to create new workflows without the need for additional programming.

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

13 Classification of non functional requirements Product Requirements Process Requirements External Requirements

14 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

15 Example (cont..) Standard Requirement The Software requirements specification should follow IEEE format. Legal constraints Pirated software should not be sold

16 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

17 RE process activities Requirements elicitation Requirements analysis Requirements specification Requirements Validation Requirements management

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

19 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

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

21 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

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

23 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?

24 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

25 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

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

27 Structured Analysis Focuses on functions/processes and data flowing between them Uses top-down decomposition approach Initially see the application as a single process and identify inputs, outputs, users and data sources Decompose the process into sub processes, show data flows for them Function Decomposition and Data Flow Diagrams (FDD, DFD) very useful

28 Physical to Logical DFDs AZ104 form 2.1 Bill checks form checked AZ104 form Master File sales order 2.1 Validate sales order valid sales order Sales orders

29 Structured Methodology Study existing system: What is done and how Prepare physical current DFD Convert this DFD to logical DFD Remove physical implementation-specific details Define boundary for automation (scope) Prepare DFD for proposed system - requires innovation, experience, vision Incorporate new needs Improve work flows (BPR: business process re-engg) Introduce efficiency/effectiveness

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

31 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]

32 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. A high-quality SRS is a prerequisite for high quality software Serve as a basis for enhancement

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

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

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

36 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)

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

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

39 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

40 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

41 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

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

43 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

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

45 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

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

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

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

49 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

50 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

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

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

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

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

55 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

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

57 3.2FUNCTIONAL REQUIREMENT Introduction Inputs Processing Outputs (Repeat Similarly For Each Function)

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

59 3.4 Design Constraints Standards Compliance Hardware Limitations

60 3.5 Software Requirement Attributes Reliability Availability Security Maintainability Portability

61 3.6 Other Requirements Possible future extensions

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

63 Requirements Validation Checks the requirements to certify that the requirements document is an acceptable description of the system to be implemented.

64 Requirements Validation Requirements review is the most common method of validation.

65 Requirements review process A group of people read and analyise the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems Plan review The review team is selected and a time and place for the review meeting is chosen Distribute documents The requirements document is distributed to the review team members Prepare for review Individual reviewers read the requirements to find conflict, omissions, inconsistencies, deviations from standards and other problems. Hold review meeting Individual comments and problems are discussed and a set of actions to address the problem is agreed. Follow-up actions The chair of the review checks that the agreed actions have been carried out. Revise document The requirements document is revised to reflect the agreed actions. At this stage it may be accepted or it may be re-reviewd.

66 Requirements review checklist Understand ability- Can readers of the document understand what the requirements mean Redundancy- Is information unnecessarily repeated in the requirements document Completeness is there any information missing from individual requirements description Ambiguity are the requirements expressed using terms which are clearly defined Organization Is the document structured in a sensible way Consistency Do the description of different requirements include contradictions Conformance to standards- Traceability

67 Requirements review problem actions Requirements clarification The requirements may be badly expressed May have accidentally omitted information Missing information Some information is missing from the requirements document Must be provided by system stakeholders Requirements conflict The stakeholders involved must negotiate to resolve the conflict Unrealistic requirements The requirements does not appear to be implemen able with the technology available or given other constraints on the system Stakeholders must be consulted to decide how to make the requirements more realistic.

68 Analysis vs Validation Analysis works with raw requirements as elicited from the system stakeholders. Usually incomplete and expressed in an informal and unstructured way Incorporation of stakeholder is important Have we got the right requirements Validation works with a final draft of the requirements document, i.e. with negotiated and agreed requirements. All known incompleteness and inconsistency are removed Validation process is more concerned with the way the in which the requirements are described Stakeholders are not necessarily important Have we got the requirements right