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

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

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

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

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

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

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

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

9. 2. Project types Project types Customer 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?

10. 2. Project types In-house development : Product 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

11. 2. Project types Time and materials based development: COTS purchase:
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)

12. 2. Project types Tender: Contract development:
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

13. 2. Project types Sub-contracting: Situation unknown:
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.

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

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

16. 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 ?

17. 5. Domain and product level
Clients
“Business” domain
Actors?
Platform
Product
User
activities
Control
computers
Domain
I/O
Product
Elevators
Product-level reqs:
The product shall accept
the following input: . . .
Domain-level req:
The product shall support
the following user activities: . . .

18. 5. Domain and product level
Redefined limits
“Business”
domain
Domain
Product
Control
computers
Clients
User
activities

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

20. 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
Product-level
Design-level
Which requirement to choose?
If the supplier is
A vendor of business applications?
A software house - programmers?
PriceWaterhouseCoopers?

21. 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”.
Both hands must be at the patient.
Electrodes, bandages, painful . . .

22. 6. The goal-design scale Recommendations : Why+ How
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
In general it is an advantage to include “business” goals’, domain descriptions and - using more caution - examples.

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

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

25. 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
 Variable price

26. 8. Case studies A personal insulin pump
An embedded system in an insulin pump used by diabetics to maintain blood glucose control.
A mental health case patient management system
A system used to maintain records of people receiving care for mental health problems.
A wilderness weather station
A data collection system that collects data about weather conditions in remote areas.

27. Insulin pump control system
Collects data from a blood sugar sensor and calculates the amount of insulin required to be injected.
Calculation based on the rate of change of blood sugar levels.
Sends signals to a micro-pump to deliver the correct dose of insulin.
Safety-critical system as low blood sugars can lead to brain malfunctioning, coma and death; high-blood sugar levels have long-term consequences such as eye and kidney damage.

28. Insulin pump hardware architecture

29. Activity model of the insulin pump

30. Essential high-level requirements
The system shall be available to deliver insulin when required.
The system shall perform reliably and deliver the correct amount of insulin to counteract the current level of blood sugar.
The system must therefore be designed and implemented to ensure that the system always meets these requirements.

31. A patient information system for mental health care
A patient information system to support mental health care is a medical information system that maintains information about patients suffering from mental health problems and the treatments that they have received.
Most mental health patients do not require dedicated hospital treatment but need to attend specialist clinics regularly where they can meet a doctor who has detailed knowledge of their problems.
To make it easier for patients to attend, these clinics are not just run in hospitals. They may also be held in local medical practices or community centres.

32. MHC-PMS
The MHC-PMS (Mental Health Care-Patient Management System) is an information system that is intended for use in clinics.
It makes use of a centralized database of patient information but has also been designed to run on a PC, so that it may be accessed and used from sites that do not have secure network connectivity.
When the local systems have secure network access, they use patient information in the database but they can download and use local copies of patient records when they are disconnected.

33. MHC-PMS goals
To generate management information that allows health service managers to assess performance against local and government targets.
To provide medical staff with timely information to support the treatment of patients.

34. The organization of the MHC-PMS

35. MHC-PMS key features Individual care management Patient monitoring
Clinicians can create records for patients, edit the information in the system, view patient history, etc. The system supports data summaries so that doctors can quickly learn about the key problems and treatments that have been prescribed.
Patient monitoring
The system monitors the records of patients that are involved in treatment and issues warnings if possible problems are detected.
Administrative reporting
The system generates monthly management reports showing the number of patients treated at each clinic, the number of patients who have entered and left the care system, number of patients sectioned, the drugs prescribed and their costs, etc.

36. MHC-PMS concerns Privacy Safety
It is essential that patient information is confidential and is never disclosed to anyone apart from authorised medical staff and the patient themselves.
Safety
Some mental illnesses cause patients to become suicidal or a danger to other people. Wherever possible, the system should warn medical staff about potentially suicidal or dangerous patients.
The system must be available when needed otherwise safety may be compromised and it may be impossible to prescribe the correct medication to patients.

37. Wilderness weather station
The government of a country with large areas of wilderness decides to deploy several hundred weather stations in remote areas.
Weather stations collect data from a set of instruments that measure temperature and pressure, sunshine, rainfall, wind speed and wind direction.
The weather station includes a number of instruments that measure weather parameters such as the wind speed and direction, the ground and air temperatures, the barometric pressure and the rainfall over a 24-hour period. Each of these instruments is controlled by a software system that takes parameter readings periodically and manages the data collected from the instruments.

38. The weather station’s environment

39. Weather information system
The weather station system
This is responsible for collecting weather data, carrying out some initial data processing and transmitting it to the data management system.
The data management and archiving system
This system collects the data from all of the wilderness weather stations, carries out data processing and analysis and archives the data.
The station maintenance system
This system can communicate by satellite with all wilderness weather stations to monitor the health of these systems and provide reports of problems.

40. Additional software functionality
Monitor the instruments, power and communication hardware and report faults to the management system.
Manage the system power, ensuring that batteries are charged whenever the environmental conditions permit but also that generators are shut down in potentially damaging weather conditions, such as high wind.
Support dynamic reconfiguration where parts of the software are replaced with new versions and where backup instruments are switched into the system in the event of system failure.

41. Key points
Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues.
Professional societies publish codes of conduct which set out the standards of behaviour expected of their members.
Three case studies are used in the book:
An embedded insulin pump control system
A system for mental health care patient management
A wilderness weather station