Ch4 Req Eng
Ch4 Req Eng
The process of establishing the services that acustomer It may range from a high-level abstract statement of a
requires from a system and the constraints under which service or of a system constraint to a detailed
it operates and is developed. mathematical functional specification.
The system requirements are the descriptions of the This is inevitable as requirements may serve a dual
function
system services and constraints that are generated
May be the basis for a bid for a contract - therefore must be open
during the requirements engineering process. to interpretation;
May be the basis for the contract itself - therefore must be
defined in detail;
Both these statements may be called requirements.
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’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract
between client and contractor.
Patients whose information is recorded in the system. A medical ethics manager who must ensure that the
Doctors who are responsible for assessing and treating system meets current ethical guidelines for patient care.
patients. Health care managers who obtain management
information from the system.
Nurses who coordinate the consultations with doctors
and administer some treatments. Medical records staff who are responsible for ensuring
Medical receptionists who manage patients’ that system information can be maintained and
appointments. preserved, and that record keeping procedures have
been properly implemented.
IT staff who are responsible for installing and maintaining
the system.
A user shall be able to search the appointments lists for These define system properties and constraints e.g.
all clinics. reliability, response time and storage requirements.
Constraints are I/O device capability, system
The system shall generate each day, for each clinic, a representations, etc.
list of patients who are expected to attend appointments
Process requirements may also be specified mandating
that day. a particular IDE, programming language or development
Each staff member using the system shall be uniquely method.
identified by his or her 8-digit employee number. Non-functional requirements may be more critical than
functional requirements. If these are not met, the system
may be useless.
The system should be easy to use by medical staff and Property Measure
should be organized in such a way that user errors are Speed Processed transactions/second
User/event response time
minimized. (Goal) Screen refresh time
Size Mbytes
Medical staff shall be able to use all the system functions Number of ROM chips
after four hours of training. After this training, the Ease of use Training time
average number of errors made by experienced users Number of help frames
shall not exceed two per hour of system use. (Testable Reliability Mean time to failure
Probability of unavailability
non-functional requirement) Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
30/10/2014 Chapter 4 Requirements Engineering 25 30/10/2014 Chapter 4 Requirements Engineering 26
Requirements engineering processes Requirements elicitation and analysis
The processes used for RE vary widely depending on Sometimes called requirements elicitation or
the application domain, the people involved and the requirements discovery.
organisation developing the requirements.
Involves technical staff working with customers to find
However, there are a number of generic activities out about the application domain, the services that the
common to all processes
system should provide and the system’s operational
Requirements elicitation;
constraints.
Requirements analysis;
Requirements validation; May involve end-users, managers, engineers involved in
Requirements management. maintenance, domain experts, trade unions, etc. These
In practice, RE is an iterative activity in which these are called stakeholders.
processes are interleaved.
Software engineers work with a range of system Stakeholders don’t know what they really want.
stakeholders to find out about the application domain, Stakeholders express requirements in their own terms.
the services that the system should provide, the required
system performance, hardware constraints, other Different stakeholders may have conflicting
systems, etc. requirements.
Stages include: Organisational and political factors may influence the
Requirements discovery, system requirements.
Requirements classification and organization, The requirements change during the analysis process.
Requirements prioritization and negotiation, New stakeholders may emerge and the business
Requirements specification. environment may change.
Requirements discovery
Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
Requirements classification and organisation
Groups related requirements and organises them into coherent
clusters.
Prioritisation and negotiation
Prioritising requirements and resolving requirements conflicts.
Requirements specification
Requirements are documented and input into the next round of
the spiral.
Scenarios and user stories are real-life examples of how Jack is a primary school teacher in Ullapool (a village in northern Scotland). He has
decided that a class project should be focused around the fishing industry in the area,
a system can be used. looking at the history, development and economic impact of fishing. As part of this,
pupils are asked to gather and share reminiscences from relatives, use newspaper
Stories and scenarios are a description of how a system archives and collect old photographs related to fishing and fishing communities in the
area. Pupils use an iLearn wiki to gather together fishing stories and SCRAN (a
may be used for a particular task. history resources site) to access newspaper archives and photographs. However,
Jack also needs a photo sharing site as he wants pupils to take and comment on
Because they are based on a practical situation, each others’ photos and to upload scans of old photographs that they may have in
stakeholders can relate to them and can comment on their families.
their situation with respect to the story. Jack sends an email to a primary school teachers group, which he is a member of to
see if anyone can recommend an appropriate system. Two teachers reply and both
suggest that he uses KidsTakePics, a photo sharing site that allows teachers to check
and moderate content. As KidsTakePics is not integrated with the iLearn
authentication service, he sets up a teacher and a class account. He uses the iLearn
setup service to add KidsTakePics to the services seen by the pupils in his class so
that when they log in, they can immediately use the system to upload photos from
their mobile devices and class computers.
30/10/2014 Chapter 4 Requirements Engineering 45 30/10/2014 Chapter 4 Requirements Engineering 46
A structured form of user story Initial assumption: A user or a group of users have one or more digital photographs
to be uploaded to the picture sharing site. These are saved on either a tablet or
laptop computer. They have successfully logged on to KidsTakePics.
Scenarios should include
Normal: The user chooses upload photos and they are prompted to select the
A description of the starting situation; photos to be uploaded on their computer and to select the project name under which
A description of the normal flow of events; the photos will be stored. They should also be given the option of inputting keywords
that should be associated with each uploaded photo. Uploaded photos are named by
A description of what can go wrong; creating a conjunction of the user name with the filename of the photo on the local
Information about other concurrent activities; computer.
A description of the state when the scenario finishes. On completion of the upload, the system automatically sends an email to the project
moderator asking them to check new content and generates an on-screen message
to the user that this has been done.
No moderator is associated with the selected project. An email is automatically Natural language The requirements are written using numbered sentences in natural language.
Each sentence should express one requirement.
generated to the school administrator asking them to nominate a project moderator.
Users should be informed that there could be a delay in making their photos visible. Structured natural The requirements are written in natural language on a standard form or
language template. Each field provides information about an aspect of the
Photos with the same name have already been uploaded by the same user. The user requirement.
should be asked if they wish to re-upload the photos with the same name, rename
the photos or cancel the upload. If they chose to re-upload the photos, the originals Design description This approach uses a language like a programming language, but with more
languages abstract features to specify the requirements by defining an operational
are overwritten. If they chose to rename the photos, a new name is automatically model of the system. This approach is now rarely used although it can be
generated by adding a number to the existing file name. useful for interface specifications.
Other activities: The moderator may be logged on to the system and may approve Graphical notations Graphical models, supplemented by text annotations, are used to define the
photos as they are uploaded. functional requirements for the system; UML use case and sequence
diagrams are commonly used.
System state on completion: User is logged on. The selected photos have been Mathematical These notations are based on mathematical concepts such as finite-state
uploaded and assigned a status ‘awaiting moderation’. Photos are visible to the specifications machines or sets. Although these unambiguous specifications can reduce
moderator and to the user who uploaded them. the ambiguity in a requirements document, most customers don’t understand
a formal specification. They cannot check that it represents what they want
and are reluctant to accept it as a system contract
Concerned with demonstrating that the requirements Validity. Does the system provide the functions which
define the system that the customer really wants. best support the customer’s needs?
Requirements error costs are high so validation is very Consistency. Are there any requirements conflicts?
important Completeness. Are all functions required by the
Fixing a requirements error after delivery may cost up to 100 customer included?
times the cost of fixing an implementation error.
Realism. Can the requirements be implemented given
available budget and technology
Verifiability. Can the requirements be checked?
Changing requirements