Beruflich Dokumente
Kultur Dokumente
² The process of establishing the services that a customer ² 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.
1) User requirements
“If a company wishes to let a contract for a large software development § Statements in natural language plus diagrams of the services the
project, it must define its needs in a sufficiently abstract way that a
system provides and its operational constraints. Written for
solution is not pre-defined. The requirements must be written so that customers.
several contractors can bid for the contract, offering, perhaps, different
ways of meeting the client organization’s needs. Once a contract has 2) System requirements
been awarded, the contractor must write a system definition for the § A structured document setting out detailed descriptions of the
client in more detail so that the client understands and can validate what system’s functions, services and operational constraints. Defines
the software will do. Both of these documents may be called the what should be implemented so may be part of a contract
requirements document for the system.” between client and contractor.
² Any person or organization who is affected by the ² Patients whose information is recorded in the system.
system in some way and so who has a legitimate interest ² Doctors who are responsible for assessing and treating
² Stakeholder types patients.
1) End users ² Nurses who coordinate the consultations with doctors
2) System managers and administer some treatments.
3) System owners
² Medical receptionists who manage patients’
4) External stakeholders
appointments.
² IT staff who are responsible for installing and maintaining
the system.
² A medical ethics manager who must ensure that the ² Many agile methods argue that producing detailed
system meets current ethical guidelines for patient care. system requirements is a waste of time as requirements
² Health care managers who obtain management change so quickly.
information from the system. ² The requirements document is therefore always out of
date.
² Medical records staff who are responsible for ensuring
that system information can be maintained and ² Agile methods usually use incremental requirements
preserved, and that record keeping procedures have engineering and may express requirements as ‘user
been properly implemented. stories’ (discussed in Chapter 3).
² This is practical for business systems but problematic for
systems that require pre-delivery analysis (e.g. critical
systems) or systems developed by several teams.
30/10/2014 Chapter 4 Requirements Engineering 11 30/10/2014 Chapter 4 Requirements Engineering 12
Functional and non-functional requirements
1) Functional requirements
§ Statements of services the system should provide, how the
system should react to particular inputs and how the system
Functional and non-functional requirements should behave in particular situations.
§ May state what the system should not do.
2) Non-functional requirements
1) Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
2) Often apply to the system as a whole rather than individual
features or services.
3) Domain requirements
§ Constraints on the system from the domain of operation
30/10/2014 Chapter 4 Requirements Engineering 13 30/10/2014 Chapter 4 Requirements Engineering 14
² Describe functionality or system services. ² A user shall be able to search the appointments lists for
² Depend on the type of software, expected users and the all clinics.
type of system where the software is used. ² The system shall generate each day, for each clinic, a
list of patients who are expected to attend appointments
² Functional user requirements may be high-level
that day.
statements of what the system should do.
² Functional system requirements should describe the ² Each staff member using the system shall be uniquely
system services in detail. identified by his or her 8-digit employee number.
² Problems arise when functional requirements are not ² In principle, requirements should be both complete and
precisely stated. consistent.
² Ambiguous requirements may be interpreted in different ² Complete
ways by developers and users. § They should include descriptions of all facilities required.
² Consider the term ‘search’ in requirement 1 ² Consistent
§ User intention – search for a patient name across all § There should be no conflicts or contradictions in the descriptions
appointments in all clinics; of the system facilities.
§ Developer interpretation – search for a patient name in an ² In practice, because of system and environmental
individual clinic. User chooses clinic then search.
complexity, it is impossible to produce a complete and
consistent requirements document.
² Non-functional requirements may be more critical than Usability Environmental Operational Development Legislative
functional requirements. If these are not met, the system requirements requirements requirements requirements requirements
may be useless.
Performance Space Accounting Safety/security
requirements requirements 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
System requirements
specification and
modeling
User requirements
specification
Requirements elicitation
Business requirements
specification
Start
Feasibility
System study
Requirements req. Requirements
elicitation elicitation User validation
requirements
elicitation Prototyping
Reviews
System requirements
document
² Sometimes called requirements elicitation or ² Stakeholders don’t know what they really want.
requirements discovery. ² Stakeholders express requirements in their own terms.
² Involves technical staff working with customers to find
² Different stakeholders may have conflicting
out about the application domain, the services that the
requirements.
system should provide and the system’s operational
constraints. ² Organisational and political factors may influence the
system requirements.
² May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These ² The requirements change during the analysis process.
are called stakeholders. New stakeholders may emerge and the business
environment may change.
1) Requirements discovery
1. Requirements § Interacting with stakeholders to discover their requirements.
discovery
Domain requirements are also discovered at this stage.
2) Requirements classification and organisation
§ Groups related requirements and organises them into coherent
4. Requirements 2. Requirements
clusters.
specification classification and
organization 3) Prioritisation and negotiation
§ Prioritising requirements and resolving requirements conflicts.
4) Requirements specification
3. Requirements
prioritization and § Requirements are documented and input into the next round of
negotiation the spiral.
² The process of gathering information about the required ² Formal or informal interviews with stakeholders are part
and existing systems and distilling the user and system of most RE processes.
requirements from this information. ² Types of interview
² Interaction is with system stakeholders from managers to § Closed interviews based on pre-determined list of questions
external regulators. § Open interviews where various issues are explored with
stakeholders.
² Systems normally have a range of stakeholders.
² Effective interviewing
§ Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
§ Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by working
together on a prototype system.
30/10/2014 Chapter 4 Requirements Engineering 35 30/10/2014 Chapter 4 Requirements Engineering 36
Interviews in practice Problems with interviews
² Normally a mix of closed and open-ended interviewing. ² Application specialists may use language to describe
² Interviews are good for getting an overall understanding their work that isn’t easy for the requirements engineer to
understand.
of what stakeholders do and how they might interact with
the system. ² Interviews are not good for understanding domain
requirements
² Interviewers need to be open-minded without pre-
conceived ideas of what the system should do § Requirements engineers cannot understand specific domain
terminology;
² You need to prompt the use to talk about the system by § Some domain knowledge is so familiar that people find it hard to
suggesting requirements rather than simply asking them articulate or think that it isn’t worth articulating.
what they want.
Requirements specification
² Requirements are written as natural language sentences ² Invent a standard format and use it for all requirements.
supplemented by diagrams and tables. ² Use language in a consistent way. Use shall for
² Used for writing requirements because it is expressive, mandatory requirements, should for desirable
intuitive and universal. This means that the requirements requirements.
can be understood by users and customers.
² Use text highlighting to identify key parts of the
requirement.
² Avoid the use of computer jargon.
² Include an explanation (rationale) of why a requirement
is necessary.
1) Lack of clarity
§ Precision is difficult without making the document difficult to 3.2 The system shall measure the blood sugar and deliver
read. insulin, if required, every 10 minutes. (Changes in blood sugar
are relatively slow so more frequent measurement is
2) Requirements confusion unnecessary; less frequent measurement could lead to
§ Functional and non-functional requirements tend to be mixed-up. unnecessarily high sugar levels.)
3) Requirements amalgamation 3.6 The system shall run a self-test routine every minute with
§ Several different requirements may be expressed together. the conditions to be tested and the associated actions defined
in Table 1. (A self-test routine can discover hardware and
software problems and alert the user to the fact the normal
operation may be impossible.)
² Use-cases are a kind of scenario that are included in the Register Export
UML. patient statistics
² Use cases identify the actors in an interaction and which View Manager
Generate
Medical receptionist personal info.
describe the interaction itself. report
² The software requirements document is the official ² Information in requirements document depends on type
statement of what is required of the system developers. of system and the approach to development used.
² Should include both a definition of user requirements ² Systems developed incrementally will, typically, have
and a specification of the system requirements. less detail in the requirements document.
² It is NOT a design document. As far as possible, it ² Requirements documents standards have been
should set of WHAT the system should do rather than designed e.g. IEEE standard. These are mostly
HOW it should do it. applicable to the requirements for large systems
engineering projects.
Requirements validation
² Validity. Does the system provide the functions which 1) Requirements reviews
best support the customer’s needs? § Systematic manual analysis of the requirements.
² Requirements for a software system set out what the ² The requirements engineering process is an iterative
system should do and define constraints on its operation process that includes requirements elicitation,
and implementation. specification and validation.
² Functional requirements are statements of the services ² Requirements elicitation is an iterative process that can
that the system must provide or are descriptions of how be represented as a spiral of activities – requirements
some computations must be carried out. discovery, requirements classification and organization,
requirements negotiation and requirements
² Non-functional requirements often constrain the system
documentation.
being developed and the development process being
used. ² You can use a range of techniques for requirements
² They often relate to the emergent properties of the elicitation such as interviews.
system and therefore apply to the system as a whole.
30/10/2014 Chapter 4 Requirements Engineering 55 30/10/2014 Chapter 4 Requirements Engineering 56
Key points Key points
² Requirements specification is the process of formally ² Requirements validation is the process of checking the
documenting the user and system requirements and requirements for validity, consistency, completeness,
creating a software requirements document. realism and verifiability.
² The software requirements document is an agreed
statement of the system requirements. It should be
organized so that both system customers and software
developers can use it.