Documente Academic
Documente Profesional
Documente Cultură
Example Example
……
4.A.5 The database shall support the generation and control of
configuration objects; that is, objects which are themselves groupings
of other objects in the database. The configuration control facilities
shall allow access to the objects in a version group by the use of an
incomplete name.
……
1
Types of requirements User requirements readers
• Written for customers • Client managers
– User requirements
• Statements in natural language plus diagrams of the • System end-users
services the system provides and its operational
constraints. • Client engineers
• Written as a contract between client and • Contractor managers
contractor
– System requirements • System architects
• A structured document setting out detailed
descriptions of the system services.
• Written for developers
– Software specification
• A detailed software description which can serve as a
basis for a design or implementation.
2
Functional requirements
• Statements of services the system
should provide, how the system
We will come back to user should react to particular inputs
and how the system should behave
and system requirements
in particular situations.
Examples of functional
Functional requirements
requirements
• Describe functionality or system services 1. The user shall be able to search either
• Depend on the type of software, all of the initial set of databases or
expected users and the type of system select a subset from it.
where the software is used 2. The system shall provide appropriate
• Functional user requirements may be viewers for the user to read documents
high-level statements of what the in the document store.
system should do but functional system 3. Every order shall be allocated a unique
requirements should describe the system identifier (ORDER_ID) which the user
services in detail shall be able to copy to the account’s
permanent storage area.
3
Requirements completeness and
Requirements imprecision
consistency
• Problems arise when requirements are • In principle, requirements should be both
not precisely stated complete and consistent
• Ambiguous requirements may be • Complete
interpreted in different ways by – They should include descriptions of all
facilities required
developers and users
• Consistent
• Consider the term ‘appropriate viewers’ – There should be no conflicts or
– User intention - special purpose viewer for contradictions in the descriptions of the
each different document type system facilities
– Developer interpretation - Provide a text • In practice, it is difficult (?impossible?)
viewer that shows the contents of the to produce a complete and consistent
document requirements document
4
Non-functional requirements Non-functional classifications
• Define system properties and constraints • Product requirements
e.g. reliability, response time and – Requirements which specify that the
storage requirements. Constraints are I/ delivered product must behave in a particular
O device capability, system way e.g. execution speed, reliability, etc.
representations, etc. • Organizational requirements
• Process requirements may also be – Requirements which are a consequence of
specified mandating a particular system, organizational policies and procedures e.g.
process standards used, implementation
programming language or development requirements, etc.
method
• External requirements
• Non-functional requirements may be – Requirements which arise from factors which
more critical than functional are external to the system and its
requirements. If these are not met, the development process e.g. interoperability
system is useless requirements, legislative requirements, etc.
5
Goals and requirements Examples
• Non-functional requirements may be very • A system goal
difficult to state precisely and imprecise – The system should be easy to use by
requirements may be difficult to verify. experienced controllers and should be
organized in such a way that user errors are
• Goal minimized.
– A general intention of the user such as ease
of use • A verifiable non-functional requirement
– Experienced controllers shall be able to use
• Verifiable non-functional requirement all the system functions after a total of two
– A statement using some measure that can be hours training. After this training, the
objectively tested average number of errors made by
• Goals are helpful to developers as they experienced users shall not exceed two per
convey the intentions of the system day.
users
6
Domain requirements Domain requirements
• Requirements that come from the • Derived from the application domain and
application domain of the system describe system characteristics and
features that reflect the domain
and that reflect characteristics of
that domain • May be new functional requirements,
constraints on existing requirements or
define specific computations
• If domain requirements are not
satisfied, the system may be unworkable
7
User requirements
• Should describe functional and non-
functional requirements so that
Back to user and system they are understandable by system
users who don’t have detailed
requirements
technical knowledge
• User requirements are defined using
natural language, tables and
diagrams
8
Editor grid requirement Requirement problems
• Grid requirement mixes three
……
different kinds of requirement
2.6 Grid facilities To assist in the positioning of entities on a diagram,
the user may turn on a grid in either centimetres or inches, via an
– Conceptual functional requirement (the
option on the control panel. Initially, the grid is off. The grid may be
need for a grid)
turned on and off at any time during an editing session and can be
– Non-functional requirement (grid units)
toggled between inches and centimetres at any time. A grid option
will be provided on the reduce-to-fit view but the number of grid
– Non-functional UI requirement (grid
lines shown will be reduced to avoid filling the smaller diagram
switching)
with grid lines.
……
9
Structured presentation Detailed user requirement
10
Problems with NL specification Alternatives to NL specification
• Ambiguity
– The readers and writers of the requirement
must interpret the same words in the same
way. NL is naturally ambiguous so this is
very difficult
• Over-flexibility
– The same thing may be said in a number of
different ways in the specification
• Lack of modularisation
– NL structures are inadequate to structure
system requirements
Structured language
Form-based specifications
specifications
• A limited form of natural language • Definition of the function or entity
may be used to express • Description of inputs and where
requirements they come from
• This removes some of the problems • Description of outputs and where
resulting from ambiguity and they go to
flexibility and imposes a degree of • Indication of other entities required
uniformity on a specification • Pre and post conditions (if
• Often best supported using a appropriate)
forms-based approach • The side effects (if any)
11
PDL-based requirements
Form-based node specification
definition
• Requirements may be defined using a
language like a programming language but
with more flexibility of expression
• Most appropriate in two situations
• Where an operation is specified as a sequence of
actions and the order is important
• When hardware and software interfaces have to be
specified
• Disadvantages are
– The program definition language (PDL) may
not be sufficiently expressive to define
domain concepts
– The specification will be taken as a design
rather than a specification
12
Interface specification PDL interface description
• Most systems must operate with other
systems and the operating interfaces
must be specified as part of the
requirements
• Three types of interface may have to be
defined
– Procedural interfaces
– Data structures that are exchanged
– Data representations
• Formal notations are an effective
technique for interface specification
13
Autoteller viewpoints Types of viewpoints
• Bank customers – Data sources or sinks
• Viewpoints are responsible for producing or consuming
• Representatives of other banks data.
• Hardware and software maintenance • Analysis involves checking that data is produced and
consumed and that assumptions about the source and
engineers sink of data are valid
• Marketing department – Representation frameworks
• Bank managers and counter staff • Viewpoints represent particular types of system
model.
• Database administrators and security • These may be compared to discover requirements
staff that would be missed using a single representation.
Particularly suitable for real-time systems
• Communications engineers – Receivers of services
• Personnel department • Viewpoints are external to the system and receive
services from it.
• Most suited to interactive systems
14
The VORD method VORD process model
• Viewpoint identification
Viewpoint
Identification
– Discover viewpoints which receive system
services and identify the services provided to
each viewpoint
Viewpoint
Structuring
• Viewpoint structuring
– Group related viewpoints into a hierarchy.
Common services are provided at higher-
Viewpoint levels in the hierarchy
Documentation
• Viewpoint documentation
– Refine the description of the identified
Viewpoint
System
viewpoints and services
Mapping • Viewpoint-system mapping
– Transform the analysis to an object-oriented
design
15
Viewpoint service information Viewpoint data/control
Account Holder Foreign Customer Bank Teller
Service List Service List Service List
Account Control Input Data Input
1. Withdraw cash 1. Withdraw cash 1. Run diagnostics Holder
2. Query balance 2. Query balance 2. Add cash 1. Start transaction 1. Card details
3. Order checks 3. Add paper 2. Cancel transaction 2. PIN
4. Send message 4. Send Message 3. End transaction 3. Amount required
5. Transaction list 4. Select service 4. Message
6. Order statement
7. Transfer funds
Customer/cash withdrawal
Viewpoint hierarchy templates
• Reference
• Reference – Cash withdrawal
Services • Rationale
– Customer
Withdraw cash – To improve customer service
• Attributes and reduce paperwork
Query balance – Account number • Specification
– PIN – Users choose this service by
– Start transaction pressing the cash withdrawal
Services button. They then enter the
• Events amount required. This is
Order checks – Select service confirmed and, if the funds
Send message – Cancel transaction are low, the balance is
delivered
Transaction list – End transaction
• VPs
Order statement • Services – Customer
Transfer funds – Cash withdrawal • Non-functional requirements
– Balance enquiry – Deliver cash within 1 minute
• Sub-VPs of amount being confirmed
– Account holder • Provider
– Filled in later
– Foreign customer
16
Scenarios Scenario descriptions
• Scenarios are descriptions of how a • System state at the beginning of
system is used in practice the scenario
• They are helpful in requirements • Normal flow of events in the
elicitation as people can relate to scenario
these more readily than abstract • What can go wrong and how this is
statement of what they require handled
from a system • Other concurrent activities
• Scenarios are particularly useful for • System state on completion of the
adding detail to an outline scenario
requirements description
17
Use cases Lending use-case
• Use-cases are a scenario based
technique in the UML which identify
the actors in an interaction and
which describe the interaction itself
• A set of use cases should describe Lending Services
all possible interactions with the
system
Actors Class of Interactions
User administration
Library
staff
Supplier
Catalog Services
18
Catalogue management: Requirements engineering
Sequence Diagram processes
Item:
Library
Books: • The processes used for RE vary widely
catalog
item depending on the application domain, the
Bookshop Cataloguer:
supplier Library staff
people involved and the organization
developing the requirements
Acquire New
• However, there are a number of generic
activities common to all processes
Catalog item – Requirements elicitation
– Requirements analysis
Dispose – Requirements validation
– Requirements management
Uncatalog item
19
Feasibility study implementation Elicit: by Webster dictionary
• Based on information assessment (what is Main Entry: elic·it
required), information collection and Pronunciation: i-'li-s&t
report writing Function: transitive verb
Etymology: Latin elicitus, past participle of
• Questions for people in the organization elicere, from e- + lacere to allure
– What if the system wasn’t implemented? Date: 1605
– What are current process problems? 1 : to draw forth or bring out (something
– How will the proposed system help? latent or potential) <hypnotism elicited his
– What will be the integration problems? hidden fears>
– Is new technology needed? What skills? 2 : to call forth or draw out (as
– What facilities must be supported by the information or a response) <her remarks
proposed system? elicited cheers>
20
The requirements analysis
process Requirements validation
Requirements • Concerned with demonstrating that
Definition &
Specification
the requirements define the system
Requirements
Validation that the customer really wants
• Requirements error costs are high
Process Domain so validation is very important
Prioritization
Entry Understanding – Fixing a requirements error after
delivery may cost up to 100 times the
Requirements Conflict cost of fixing an implementation error
Collection Resolution
Classification
Requirements validation
Requirements Validation
• Validity. Does the system provide the
techniques
• Requirements reviews
functions that best support the – Systematic manual analysis of the
customer’s needs? requirements
• Consistency. Are there any requirements • Prototyping
conflicts? – Using an executable model of the system to
check requirements.
• Completeness. Are all functions required
by the customer included? • Test-case generation
• Realism. Can the requirements be – Developing tests for requirements to check
testability
implemented given available budget and
technology • Automated consistency analysis
– Checking the consistency of a structured
• Verifiability. Can the requirements be requirements description
checked?
21
Requirements reviews Review checks
• Regular reviews should be held while the • Verifiability. Is the requirement
requirements definition is being realistically testable?
formulated
• Comprehensibility. Is the
• Both client and contractor staff should
be involved in reviews
requirement properly understood?
• Reviews may be formal (with completed • Traceability. Is the origin of the
documents) or informal. Good requirement clearly stated?
communications between developers, • Adaptability. Can the requirement
customers and users can resolve problems
be changed without a large impact
at an early stage
on other requirements?
22
Traceability A traceability matrix
• Traceability is concerned with the
relationships between requirements, their
sources and the system design
• Source traceability
– Links from requirements to stakeholders who
proposed these requirements
• Requirements traceability
– Links between dependent requirements
• Design traceability
– Links from the requirements to the design
U = “uses the requirement”, R = “Some other weaker relationship”
23
Enduring and volatile
Requirements change
requirements
• Enduring requirements. Stable • The priority of requirements from
requirements derived from the core different viewpoints changes during
activity of the customer organisation. the development process
E.g. a hospital will always have doctors,
nurses, etc. May be derived from domain • System customers may specify
models requirements from a business
• Volatile requirements. Requirements perspective that conflict with end-
which change during development or when user requirements
the system is in use. In a hospital, • The business and technical
requirements derived from health-care
policy environment of the system changes
during its development
24
Requirements evolution Requirements change management
• Should apply to all proposed changes to
Initial Changed
understanding understanding the requirements
of problem of problem • Principal stages
– Problem analysis. Discuss requirements
problem and propose change
– Change analysis and costing. Assess effects
Initial Changed
of change on other requirements
requirements requirements
– Change implementation. Modify requirements
document and other documents to reflect
change
Time
25
Users of a requirements Requirements document
document requirements
– System customers • Specify external system behaviour
• Specify the requirements and read them to check
that they meet their needs • Specify implementation constraints
– Managers • Easy to change
• Use the requirements document to plan a bid for the
system and to plan the system • Serve as reference tool for maintenance
– System engineers • Record forethought about the life cycle
• Use the requirements to understand what system is
to be developed of the system i.e. predict changes
– System test engineers • Characterise responses to unexpected
• Use the requirements to develop validation tests for events
the system
– System maintenance engineers
• Use the requirements to help understand the system
and the relationship between its parts
26