Module T04 Software Engineering. Requirements Engineering

Transcription

1 Module T04 Software Engineering Requirements Engineering 1

2 Overview 2

3 Requirements Engineering Produces one large document written in natural language contains a description of what the system will do without describing how it will do it Without well written document Developers do not know what to build Customers do not know what to expect What to validate Requirements describe what not how 3

4 What is a Requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification May serve a dual function May be the basis for a bid for a contract - therefore must be open to interpretation May be the basis for the contract itself - therefore must be defined in detail Both these statements may be called requirements Stakeholder: Anyone who should have some direct or indirect influence on the system requirements. 4

5 Functional vs non-functional requirements Functional requirements describe what the software has to do. They are often called product features. Non-functional requirements mostly quality requirements. That stipulate how well the software does, what it has to do. 5

6 Types of requirement User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers System requirements A structured document setting out detailed descriptions of the system services. Derived from user requirement. Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers 6

7 Requirements User requirements Client managers System end-users Client engineers Contractor managers System architects System requirements System end-users Client engineers System architects Software developers Software design specification Client engineers (perhaps) System architects Software developers 7

8 Requirement Process 8

9 Requirements Engineering Process Feasibility study Feasibility report Requirements elicitation and analysis System models Requirements specification User and system requirements Requirements validation Requirements document 9

10 Feasibility study Is cancellation of a project a bad news? As per IBM report, 31% projects get cancelled before they are completed, 53% over-run their cost estimates by an average of 189% & for every 100 projects, there are 94 restarts. How do we cancel a project with the least work? CONDUCT A FEASIBILTY STUDY 10

11 Feasibility study A feasibility study decides whether or not the proposed system is worthwhile Focus of feasibility studies Is the product concept viable? Will it be possible to develop a product that matches the project s vision statement? Are the project s cost and schedule assumption realistic? Is the business model realistic? Is there any market for the product? What will be the integration problems? Is new technology needed? What skills? 11

12 Requirements Elicitation Sometimes called requirements elicitation or requirements discovery Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system s operational constraints Perhaps Most difficult Most critical Most error prone Most communication intensive 12

13 Requirements Elicitation Interviews Brainstorming Sessions group discussions: new ideas quickly, creative thinking Idea is to generate views,not to vet them Facilitated Application specification Techniques (FAST) Similar to brainstorming sessions. Creation of joint team of customers and developers Involvement of a facilitator Quality Function Deployment Incorporate voice of the customer What is important for customer Degree of importance to each requirement The Use Case Approach 13

14 Requirements Analysis Analyze, refine and scrutinize requirements to make consistent & unambiguous requirements. 14

15 Analysis phase Purposes of analysis: To capture requirements To represent requirements in models Products of the analysis phase Requirement model: to describe system functionality. Use cases are used here. Analysis model: to describe objects that accomplish system functionality. We will cover the many types of model in the next module 15

16 Requirement Specification Walking on water and developing software from a specification are easy if both are frozen. Edward Berard 16

17 The requirements document The requirements document is the official statement of what is required of the system developers Should include both a definition and a specification of requirements It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it Serves as contract between customer & developer. 17

18 Nature of SRS Basic Issues Functionality External Interfaces Performance Attributes Design constraints SRS Should Correctly define all requirements not describe any design details not impose any additional constraints An SRS Should be Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable 18

19 Users of a requirements document System customers Managers System engineers Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements Use the requirements document to plan a bid for the system and to plan the system development process Use the requirements to understand what system is to be developed System test engineers Use the requirements to develop validation tests for the system System maintenance engineers Use the requirements to help understand the system and the relationships between its parts 19

20 IEEE Standards IEEE has published guidelines and standards for software engineering. IEEE Software Document Definitions Standard Acronym Document IEEE 730 SQAP Software Quality Assurance Plan IEEE 828 SCMP Software Configuration Management Plan IEEE 829 STD Software Test Documentation IEEE 830 SRS Software requirements specification IEEE 1012 SVVP Software Validation & Verification IEEE 1016 SDD Software Design Descri IEEE 1058 SPMP Software Project Management Plan IEEE 1063 SUD Software User Documentation 20

21 Organization of the SRS SRS Software requirements specification IEEE 830 First two sections are same. The specific tailoring occurs in section-3. 21

22 Organization of the SRS 22

23 Requirement Validation 23

24 Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wants Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error Check the document for: Completeness & consistency Conformance to standards Requirements conflicts Technical errors Ambiguous requirements 24

25 25

26 Requirements validation 26

27 Requirements validation techniques Requirements reviews Systematic manual analysis of the requirements Prototyping Using an executable model of the system to check requirements. Test-case generation Developing tests for requirements to check testability Automated consistency analysis Checking the consistency of a structured requirements description 27