IS550: Software requirements engineering

1. IS550: Software requirements engineering • 1. Introduction and basic concepts Dr. Azeddine Chikh

2. Text Soren Lauesen, "Software Requirements: Styles & Techniques"Addison-Wesley Professional 2002,  608 pp, ISBN-10: 0201745704 - ISBN-13: 9780201745702

3. Validation Verification 1. The role of requirements Tacit demands & reqs Stakeholders Demands Elicitation Analysis Contract Reqspec Design Tracing: Forwards . . . Backwards . . . Req. management: Changing reqs Program Test Op & maint

4. 1. The role of requirements • Tacit demands : are necessary – we cannot specify everything • Elicitation and analysis : finding and structuring requirements • Validation: the customers check that requirements match demands • Verification: checking that the product fulfills the requirements

5. 1. The role of requirements • Tracing : is needed to compare requirements against other information. There are 4 types of tracing • Forward: • Tracing from requirements to program • Tracing from demands to requirements • Backward: • Tracing from program to requirements • Tracing from requirements to demands

6. 1. The role of requirements • Req. management : in spite of attempts to get it right the first time requirements change during development. It must be easy to update the specification, add new requirements, and asses the consequences of change.

7. 2. Project types • There are many types of project: • in-house development • buying commercial software • tenders and contracts, etc. • Requirements have different roles in different types of projects • Sometimes the project type is unknown

8. 2. Project types Project typesCustomer Supplier In-house User dept. IT dept. Prod. devel. Marketing SW dept. Time & materials Company SW house COTS Company (Vendor) Tender Company Supplier Contract devel. Company SW house Sub-contracting Supplier SW house Unknown Inhouse? COTS?

9. 2. Project types • In-house development : • The system is developed inside a company for the company’s own use. • The customer and the supplier are departments of the same company • Larger companies: banks, insurance comp., … • Product development : • The product is a commercial software to be marketed by a company • The development project is carried out inside the company. The customer is the marketing department and the supplier the development department

10. 2. Project types • Time and materials based development: • A software house develops the system on a time-and-materials base, i-e the customer pays the costs, for instance month by month • Requirements are informal (unwritten) and develop over time • Over time, the parties tend to realize that such projects can easily get out of control. • COTS purchase: • Commercial Off The Shelf that we can buy from the market (more or less off the shelf) : MS-Office, development tools, hospital and bank systems • We distinguish COTS purchase (fully off the shelf) from COTS based (including some tailor-made configuration or extension)

11. 2. Project types • Tender: • The costumer company starts a tender process and sends out a request for proposal (RFP). • Several suppliers are invited to submit proposals • The tender documentation contains an elaborate requirement specification • The customer selects the best proposal • Contract development: • A supplier company develops or delivers a system to the customer company. The requirements specification and the contract specify what is to be delivered • The two parties will often work together for some time to write the requirements and the contract. • The system may be tailor-made or a COTS-based system with extensions

12. 2. Project types • Sub-contracting: • A subcontractor develops or delivers part of the system to a main contractor, who delivers the total system to a customer. Sub-contracting can be requirements-based or time-and-materials based without written requirements • Situation unknown: • In many cases the customer doesn’t know what should do. Should he buy a COTS system or have the system developed in-house ? Should he try to integrate several products or should he contract with someone else to do it? • High-level requirements can help to resolve these issues. They may help compare the alternatives from a cost/benefit and risk perspective.

13. 3. Contents of ReqSpec Quality reqs: Performance Usability Maintainability . . . Other deliverables: Documentation Install system Convert data Train users. . . Interfaces User groups Platform: HW, OS, DB Spreadsheet System Ext. products: Sensors, dev. Special SW Managerial reqs: Delivery time Legal Intellectual properties Development . . . Helping the reader: Background (Rationale) Business goals Definitions Diagrams . . . Organizing the parts: Best-known standard : IEEE 830 Data requirements: System state: Database, comm. states Input/output formats Functional requirements, each interface: Record, compute, transform, transmit Theory: F(input, state) -> (output, state) Function list, pseudo-code, activity diagram Screen prototype, support tasks xx to yy

14. 4. Problems observed in practice • Relatively few problems in data and functional requirements • Serious problems ensuring efficient task support and meeting business goals • Quality requirements : important, but what should be written ? • Parts to help the reader : important, but often ignored

15. 5. Domain and product level • Product : the system to be delivered • Product-level requirements : specify what should come in and out of the product. • Domain : the product and its immediate users and other surroundings • Domain-level requirements : describe the activities that go on outside the product – in the domain. The req. are to support those activities • Quality req. can be at a product level as well as at a domain level. • Example :performance • 1: Product level : response time for the computer system (1) • 2 : Domain level : performance time for a user task = manual time + (1) • Clients : people served by the domain • System : the product, the domain, or software plus hardware ?

16. 6. The goal-design scale • A requirement must specify what the system should do without specifying how. • Goal-level requirement : why the customer wants to spend money on the product • Domain-level requirement : supports user tasks xx to yy • Product-level requirement : a function to be provided by the product • Design-level requirement : details of the product interface

17. 6. The goal-design scale R1. Our pre-calculations shall hit within 5% R2. Product shall support cost recording and quotation with experience data R3. Product shall have recording and retrieval functions for experience data R4. System shall have screen pictures as shown in app. xx Goal-level requirement Domain-level requirement Product-level requirement Design-level requirement Which requirement to choose? If the supplier is A vendor of business applications? A software house - programmers? PriceWaterhouseCoopers?

18. 6. The goal-design scale Ask “why” Neural diagnostics System shall have mini keyboard with start/stop button, . . . Why? Possible to operate it with “left hand”. Why? Both hands must be at the patient. Why? Electrodes, bandages, painful . . .

19. 6. The goal-design scale Recommendations : Why+ How • In general it is an advantage to include “business” goals’, domain descriptions and - using more caution - examples. Measuring neural response is a bit painful to the patient. Electrodes must be kept in place . . . So both hands should be at the patient during a measurement. R1: It shall be possible to perform the commands start, stop, . . . with both hands at the patient. Might be done with mini keyboard (wrist keys), foot pedal, voice recognition, etc. Domain - why Req. Example - how

20. 7. Typical project models • Product-level requirements : elicited from users. A lot of work • Domain-level requirements : describe user tasks. Much faster. • Two-step approach : domain-level first, design-level later with careful checks

21. 7. Typical project models Approaches • Traditional: Product-level reqs • Ask users, study documents, . . . • extract features/functions. • Intro, [business goals] . . . • System limits, e.g. context diagram • Data reqs, e.g. data model, data descr. • Product-level funct. reqs, e.g. features • Critical quality reqs • Two-step approach: • Domain-level + design-level • All the fast-approach stuff • + • Design-level reqs, e.g. • prototypes, comm.protocols • Fast approach: Domain-level • Describe user tasks, study documents . . . • Intro, [business goals, BPR tasks] . . . • System limits, e.g. context diagram • Data reqs, e.g. verbal data descr. • Domain-level reqs, e.g. Tasks & Support • [Trace analysis: goals to tasks] • Critical quality reqs

22. 7. Typical project models Recommended project models Project model Project type: Trad. Domain Two-step In-house ? OK OK Product dev. ? OK Time & mat. ? OK OK COTS business ? OK COTS tools OK Tender COTS ? OK Tender tailor ? OK OK Contract COTS ? OK Contract tailor ? OK OK Sub-contract OK OK Maintenance OK ? Used, but dubious