2. Requirements engineering
• The process of establishing the services that
the customer requires from a system and the
constraints under which it operates and is
developed.
• The requirements themselves are the
descriptions of the system services and
constraints that are generated during the
requirements engineering process.
3. 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
dual function
– 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.
4. 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.
5. 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
7. 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.
8. Functional requirements
• 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.
9. 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.
10. 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
store.
• 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.
11. Requirements imprecision(problem)
• Problems arise when requirements are not
precisely stated.
• 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.
12. Requirements completeness and consistency
• In principle, requirements should be both complete and
consistent.
• Complete
– They should include descriptions of all facilities
required.
• Consistent
– There should be no conflicts or contradiction in
the descriptions of the system facilities.
.
13. Non-functional requirements
• 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
method.
• Non-functional requirements may be more
critical than functional requirements. If these are
not met, the system is useless.
14. Non-functional classifications
• 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
requirements, etc.
• External requirements
– Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
15. Non-functional requirement types
Perfor mance
requir ements
Space
requir ements
Usa bility
requir ements
Efficiency
requir ements
Relia bility
requir ements
Porta bility
requir ements
Inter oper a bility
requir ements
Ethical
requir ements
Leg isla tive
requir ements
Implementa tion
requir ements
Standar ds
requir ements
Deli very
requir ements
Safety
requir ements
Pri vacy
requir ements
Product
requir ements
Organisational
requir ements
External
requir ements
Non-functional
requir ements
16. 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
system.
17. The requirements document
• The requirements document is the official
statement of what is required of the system
developers.
• Should include both a definition of user
requirements and a specification of the
system requirements.
• 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
19. Requirements document structure
• Preface
• Introduction
• Glossary
• User requirements definition
• System architecture
• System requirements specification
• System models
• System evolution
• Appendices
• Index
20. IEEE requirements standard
• Defines a generic structure for a requirements
document that must be instantiated for each
specific system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.
21. Requirements engineering processes
• The processes used for RE vary widely depending
on the application domain, the people involved
and the organisation developing the
requirements.
• However, there are a number of generic activities
common to all processes
– Feasibility studies
– Requirements elicitation;
– Requirements analysis;
– Requirements validation;
– Requirements management.
24. 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
objectives;
– If the system can be engineered using current
technology and within budget;
– If the system can be integrated with other systems
that are used.
25. 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
system?
26. Software prototyping
• A prototype is an initial version of a system
used to demonstrate concepts and try out
design options.
• 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.
27. Prototyping
• 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.
28. Benefits of prototyping
• Improved system usability.
• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.
31. Throw-away prototypes
• 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
non-functional requirements;
– Prototypes are normally undocumented;
– The prototype structure is usually degraded
through rapid change;
– The prototype probably will not meet normal
organisational quality standards.
32. TCS2411 Software Engineering 32
Functional Modeling
• 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
transformed
33. Data-processing models
• 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
methods.
• Simple and intuitive notation that customers
can understand.
• Show end-to-end processing of data.
35. Data flow diagrams
• DFDs model the system from a functional
perspective.
• 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.
37. Behavioural models
• 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
system’s behaviour.
38. 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.
39. Statecharts
• 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.
40. 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
readyÕ.
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.
41. 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
43. Semantic data models
• Used to describe the logical structure of data processed by
the system.
• An entity-relation-attribute model sets out the entities in the
system, the relationships between these entities and the
entity attributes
• 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.
45. Structured methods(analysis)
• 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.
46. Method weaknesses
• They do not model non-functional system
requirements.
• They do not usually include information about
whether a method is appropriate for a given
problem.
• The may produce too much documentation.
• The system models are sometimes too
detailed and difficult for users to understand.
47. CASE workbenches
• 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
model.
48. An analysis and design workbench
Centr al
infor ma tion
repository
Code
gener ator
Query
langua ge
facilities
Structur ed
dia g ramming
tools
Da ta
dictionary
Repor t
gener a tion
facilities
Design, anal ysis
and checking
tools
For ms
cr ea tion
tools
Impor t/e xpor t
facilities
49. 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
50. Data dictionaries
• Data dictionaries are lists of all of the names used in
the system models. Descriptions of the
entities, relationships and attributes are also
included.
• Advantages
– Support name management and avoid
duplication;
– Store of organisational knowledge linking
analysis, design and implementation;
• Many CASE workbenches support data dictionaries.
51. Data dictionary entries
Name Description Typ e Date
Artic le
Deta ils of the published article that may be ord ered by
people using LI BSYS .
Entity 30.12.2002
authors
The nam es of the authors of the artic le who may be due
a share of the f ee.
Attribute 30.12.2002
Buyer
The person or org anis ation that orders a co py of the
article .
Entity 30.12.2002
fee-
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
Address
(Buyer)
The address of the buyer. Th is is used to any paper
billing inform ation t hat is required.
Attribute 31.12.2002
