0% found this document useful (0 votes)
3 views6 pages

Ch4 Req Eng

Requirements engineering involves establishing the services and constraints of a system, generating user and system requirements, and identifying stakeholders affected by the system. It includes functional and non-functional requirements, with the latter often being critical to system usability and performance. The process is iterative, involving elicitation, analysis, validation, and management of requirements to ensure they meet customer needs and can be implemented effectively.

Uploaded by

ipekzel2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views6 pages

Ch4 Req Eng

Requirements engineering involves establishing the services and constraints of a system, generating user and system requirements, and identifying stakeholders affected by the system. It includes functional and non-functional requirements, with the latter often being critical to system usability and performance. The process is iterative, involving elicitation, analysis, validation, and management of requirements to ensure they meet customer needs and can be implemented effectively.

Uploaded by

ipekzel2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Requirements engineering What is a requirement?

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

30/10/2014 Chapter 4 Requirements Engineering 3 30/10/2014 Chapter 4 Requirements Engineering 4

Types of requirement User and system 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.

30/10/2014 Chapter 4 Requirements Engineering 6 30/10/2014 Chapter 4 Requirements Engineering 7

Readers of different types of requirements


System stakeholders
specification

 Any person or organization who is affected by the


system in some way and so who has a legitimate interest
 Stakeholder types
 End users
 System managers
 System owners
 External stakeholders

30/10/2014 Chapter 4 Requirements Engineering 8 30/10/2014 Chapter 4 Requirements Engineering 9


Stakeholders in the Mentcare system Stakeholders in the Mentcare system

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

30/10/2014 Chapter 4 Requirements Engineering 10 30/10/2014 Chapter 4 Requirements Engineering 11

Functional and non-functional requirements Functional requirements

 Describe functionality or system services.


 Functional requirements
 Statements of services the system should provide, how the  Depend on the type of software, expected users and the
system should react to particular inputs and how the system type of system where the software is used.
should behave in particular situations.
 May state what the system should not do.  Functional user requirements may be high-level
 Non-functional requirements statements of what the system should do.
 Constraints on the services or functions offered by the system  Functional system requirements should describe the
such as timing constraints, constraints on the development system services in detail.
process, standards, etc.
 Often apply to the system as a whole rather than individual
features or services.
 Domain requirements
 Constraints on the system from the domain of operation
30/10/2014 Chapter 4 Requirements Engineering 14 30/10/2014 Chapter 4 Requirements Engineering 15

Mentcare system: functional requirements Non-functional requirements

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

30/10/2014 Chapter 4 Requirements Engineering 16 30/10/2014 Chapter 4 Requirements Engineering 19


Non-functional requirements implementation Non-functional classifications

 Non-functional requirements may affect the overall  Product requirements


architecture of a system rather than the individual  Requirements which specify that the delivered product must
components. behave in a particular way e.g. execution speed, reliability, etc.
 For example, to ensure that performance requirements are met,  Organisational requirements
you may have to organize the system to minimize
 Requirements which are a consequence of organisational
communications between components.
policies and procedures e.g. process standards used,
 A single non-functional requirement, such as a security implementation requirements, etc.
requirement, may generate a number of related  External requirements
functional requirements that define system services that
 Requirements which arise from factors which are external to the
are required. system and its development process e.g. interoperability
 It may also generate requirements that restrict existing requirements, legislative requirements, etc.
requirements.

30/10/2014 Chapter 4 Requirements Engineering 21 30/10/2014 Chapter 4 Requirements Engineering 22

Examples of nonfunctional requirements in the


Goals and requirements
Mentcare system

 Non-functional requirements may be very difficult to state


Product requirement
The Mentcare system shall be available to all clinics during normal
precisely and imprecise requirements may be difficult to
working hours (Mon–Fri, 0830–17.30). Downtime within normal verify.
working hours shall not exceed five seconds in any one day.
 Goal
Organizational requirement  A general intention of the user such as ease of use.
Users of the Mentcare system shall authenticate themselves using
their health authority identity card.  Verifiable non-functional requirement
External requirement  A statement using some measure that can be objectively tested.
The system shall implement patient privacy provisions as set out in  Goals are helpful to developers as they convey the
HStan-03-2006-priv.
intentions of the system users.

30/10/2014 Chapter 4 Requirements Engineering 23 30/10/2014 Chapter 4 Requirements Engineering 24

Metrics for specifying nonfunctional


Usability requirements
requirements

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

30/10/2014 Chapter 4 Requirements Engineering 28 30/10/2014 Chapter 4 Requirements Engineering 31

Requirements elicitation Problems of requirements elicitation

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

30/10/2014 Chapter 4 Requirements Engineering 33 30/10/2014 Chapter 4 Requirements Engineering 34

The requirements elicitation and analysis


Process activities
process

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

30/10/2014 Chapter 4 Requirements Engineering 35 30/10/2014 Chapter 4 Requirements Engineering 36


Stories and scenarios Photo sharing in the classroom (iLearn)

 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

Scenarios Uploading photos iLearn)

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

30/10/2014 Chapter 4 Requirements Engineering 47 30/10/2014 Chapter 4 Requirements Engineering 48

Ways of writing a system requirements


Uploading photos
specification

 What can go wrong: Notation Description

 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

30/10/2014 Chapter 4 Requirements Engineering 49 30/10/2014 Chapter 4 Requirements Engineering 52


Requirements validation Requirements checking

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

30/10/2014 Chapter 4 Requirements Engineering 72 30/10/2014 Chapter 4 Requirements Engineering 73

Requirements validation techniques Review checks

 Requirements reviews  Verifiability


 Systematic manual analysis of the requirements.  Is the requirement realistically testable?
 Prototyping  Comprehensibility
 Using an executable model of the system to check requirements.  Is the requirement properly understood?
Covered in Chapter 2.
 Traceability
 Test-case generation  Is the origin of the requirement clearly stated?
 Developing tests for requirements to check testability.
 Adaptability
 Can the requirement be changed without a large impact on other
requirements?

30/10/2014 Chapter 4 Requirements Engineering 74 30/10/2014 Chapter 4 Requirements Engineering 76

Changing requirements

 The business and technical environment of the system


always changes after installation.
 New hardware may be introduced, it may be necessary to
interface the system with other systems, business priorities may
change (with consequent changes in the system support
required), and new legislation and regulations may be introduced
that the system must necessarily abide by.
 The people who pay for a system and the users of that
system are rarely the same people.
 System customers impose requirements because of
organizational and budgetary constraints. These may conflict
with end-user requirements and, after delivery, new features may
have to be added for user support if the system is to meet its
goals.
30/10/2014 Chapter 4 Requirements Engineering 78

You might also like