• The process of establishing the services that
the customer requires from a system and the
constraints under which it operates and is
• The requirements themselves are the
descriptions of the system services and
constraints that are generated during the
requirements engineering process.
What is a requirement?
• It may range from a high-level abstract statement
of a service or of a system constraint to a detailed
mathematical functional specification.
• This is inevitable as requirements may serve a
– May be the basis for a offer for a contract - therefore
must be open to interpretation(explanation);
– May be the basis for the contract itself - therefore
must be defined in detail;
– Both these statements may be called requirements.
Types of requirement
• 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.
Definitions and specifications
System req specification: Extenal file+have a ass
tool+it display spec icon for user +provide facility
for icon it represent external file type
User req Definitions: representing and
access EXT files created by other tools
Functional and non-functional requirements
• Functional requirements
– Statements of services the system should provide, how the
system should react to particular inputs and how the
system should behave in particular situations.
• Non-functional requirements
– constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
• Domain requirements
– Requirements that come from the application domain of
the system and that reflect characteristics of that domain.
• Describe functionality or system services.
• Depend on the type of software, expected
users and the type of system where the
software is used.
• Functional user requirements may be high-
level statements of what the system should do
but functional system requirements should
describe the system services in detail.
The LIBSYS system
• A library system that provides a single
interface to a number of databases of articles
in different libraries.
• Users can search for, download and print
these articles for personal study.
Examples of functional requirements
• The user shall be able to search either all of the
initial set of databases or select a subset from it.
• The system shall provide appropriate viewers for
the user to read documents in the document
• Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy
to the account’s permanent storage area.
• Problems arise when requirements are not
• Ambiguous requirements may be interpreted
in different ways by developers and users.
• Consider the term ‘appropriate viewers’
– User intention - special purpose viewer for each
different document type;
– Developer interpretation - Provide a text viewer
that shows the contents of the document.
Requirements completeness and consistency
• In principle, requirements should be both complete and
– They should include descriptions of all facilities
– There should be no conflicts or contradiction in
the descriptions of the system facilities.
• These define system properties and constraints
e.g. reliability, response time and storage
requirements. Constraints are I/O device
capability, system representations, etc.
• Process requirements may also be specified
mandating a particular CASE
system, programming language or development
• Non-functional requirements may be more
critical than functional requirements. If these are
not met, the system is useless.
• Product requirements
– Requirements which specify that the delivered product must behave in
a particular way e.g. execution speed, reliability, etc.
• Organisational requirements
– Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation
• External requirements
– Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Non-functional requirement types
Inter oper a bility
Leg isla tive
Non-functional requirements examples
• Product requirement
The user interface for LIBSYS shall be implemented as simple HTML
without frames or Java applets.
• Organisational requirement
The system development process and deliverable documents shall conform
to the process and deliverables.
• External requirement
The system shall not disclose any personal information about customers
apart from their name and reference number to the operators of the
The requirements document
• The requirements document is the official
statement of what is required of the system
• Should include both a definition of user
requirements and a specification of the
• It is NOT a design document. As far as
possible, it should set of WHAT the system
should do rather than HOW it should do it
Requirements document structure
• User requirements definition
• System architecture
• System requirements specification
• System models
• System evolution
IEEE requirements standard
• Defines a generic structure for a requirements
document that must be instantiated for each
– General description.
– Specific requirements.
Requirements engineering processes
• The processes used for RE vary widely depending
on the application domain, the people involved
and the organisation developing the
• However, there are a number of generic activities
common to all processes
– Feasibility studies
– Requirements elicitation;
– Requirements analysis;
– Requirements validation;
– Requirements management.
Syst em requirements
Feasibility studies[possible analysis]
• A feasibility study decides whether or not the
proposed system is worthwhile.
• A short focused study that checks
– If the system contributes to organisational
– If the system can be engineered using current
technology and within budget;
– If the system can be integrated with other systems
that are used.
Feasibility study implementation
• Based on information assessment (what is required),
information collection and report writing.
• Questions for people in the organisation
– What if the system wasn’t implemented?
– What are current process problems?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed
• A prototype is an initial version of a system
used to demonstrate concepts and try out
• A prototype can be used in:
– The requirements engineering process to help
with requirements elicitation and validation;
– In design processes to explore options and
develop a UI design;
– In the testing process to run back-to-back tests.
• For some large systems, incremental iterative
development and delivery may be impractical;
this is especially true when multiple teams are
working on different sites.
• Prototyping, where an experimental system is
developed as a basis for formulating the
requirements may be used. This system is
thrown away when the system specification
has been agreed.
Benefits of prototyping
• Improved system usability.
• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.
• Prototypes should be discarded after
development as they are not a good basis for
a production system:
– It may be impossible to tune the system to meet
– Prototypes are normally undocumented;
– The prototype structure is usually degraded
through rapid change;
– The prototype probably will not meet normal
organisational quality standards.
TCS2411 Software Engineering 32
• In understanding the requirements of the
software, the functions required by the
customer will be identified
• All the functions process information in some
way in the system
• Basically input process output
• Representation of how information is
• Data flow diagrams (DFDs) may be used to
model the system’s data processing.
• These show the processing steps as data flows
through a system.
• DFDs are an intrinsic part of many analysis
• Simple and intuitive notation that customers
• Show end-to-end processing of data.
Data flow diagrams
• DFDs model the system from a functional
• Tracking and documenting how the data
associated with a process is helpful to develop
an overall understanding of the system.
• Data flow diagrams may also be used in
showing the data exchange between a system
and other systems in its environment.
• Behavioural models are used to describe the
overall behaviour of a system.
• Two types of behavioural model are:
– Data processing models that show how data is
processed as it moves through the system;
– State machine models that show the systems
response to events.
• These models show different perspectives so
both of them are required to describe the
State machine models
• These model the behaviour of the system in response to
external and internal events.
• They show the system’s responses to stimuli so are often used
for modelling real-time systems.
• State machine models show system states as nodes and
events as arcs between these nodes. When an event occurs,
the system moves from one state to another.
• Statecharts are an integral part of the UML and are used to
represent state machine models.
• Allow the decomposition of a model into sub-
models (see following slide).
• A brief description of the actions is included
following the ‘do’ in each state.
• Can be complemented by tables describing
the states and the stimuli.
Microwave oven state description
Stat e Description
W aiting The o ven is wa iting for input. The display shows the currentt ime.
Half p ower The o ven pow er is set to 300 w atts. The d is play shows ŌHalf p owerÕ.
Full power The o ven pow er is set to 600 w atts. The d is play shows ŌFull powerÕ.
Set time The cooking time is s et to the userÕs input value. The display shows the cooking time
select ed and is updated as the t im e is s et.
Disabled Oven operation is dis abled for safety. Interior oven light is on. Dis play shows ŌNot
Enabled Oven o peration is enabled. Interior oven light is off. Display s how s ŌReady to cookÕ.
Operation Oven in operation. Interior oven light is on. Display shows the tim er countdow n. On
com pletion of cooking, the buzz er is sounded for 5 s econds. Oven light is on. Dis play
shows ŌCooking com pleteÕ while buzze r is sounding.
Microwave oven stimuli
Stim ulus Description
Half p ow er The u ser has pr essed the half pow er button
Full power The u ser has pr essed the full pow er button
Time r The u ser has pr essed one of the tim er buttons
Numb er The u ser has pr essed a numeric ke y
Door open The o ven door sw itch is n ot closed
Door closed The o ven door sw itch is closed
Start The u ser has pr essed the start button
Cance l The u ser has pr essed the ca ncel button
Semantic data models
• Used to describe the logical structure of data processed by
• An entity-relation-attribute model sets out the entities in the
system, the relationships between these entities and the
• Widely used in database design. Can readily be implemented
using relational databases.
• No specific notation provided in the UML but objects and
associations can be used.
• Structured methods incorporate system
modelling as an inherent part of the method.
• Methods define a set of models, a process for
deriving these models and rules and
guidelines that should apply to the models.
• CASE tools support system modelling as part
of a structured method.
• They do not model non-functional system
• They do not usually include information about
whether a method is appropriate for a given
• The may produce too much documentation.
• The system models are sometimes too
detailed and difficult for users to understand.
• A coherent set of tools that is designed to
support related software process activities
such as analysis, design or testing.
• Analysis and design workbenches support
system modelling during both requirements
engineering and system design.
• These workbenches may support a specific
design method or may provide support for a
creating several different types of system
An analysis and design workbench
infor ma tion
dia g ramming
gener a tion
Design, anal ysis
cr ea tion
Impor t/e xpor t
Analysis workbench components
• Diagram editors
• Model analysis and checking tools
• Repository and associated query language
• Data dictionary
• Report definition and generation tools
• Forms definition tools
• Import/export translators
• Code generation tools
• Data dictionaries are lists of all of the names used in
the system models. Descriptions of the
entities, relationships and attributes are also
– Support name management and avoid
– Store of organisational knowledge linking
analysis, design and implementation;
• Many CASE workbenches support data dictionaries.
Data dictionary entries
Name Description Typ e Date
Deta ils of the published article that may be ord ered by
people using LI BSYS .
The nam es of the authors of the artic le who may be due
a share of the f ee.
The person or org anis ation that orders a co py of the
paya ble -to
A 1:1 relationship between Artic le and the Copyrig ht
Agency w ho should b e paid the copyright fee.
Rela tio n 29.12.2002
The address of the buyer. Th is is used to any paper
billing inform ation t hat is required.