Software Engineering

1
Software Engineering

• Requirement Analysis
• (Concepts and Principles)
• Attila Kovács

2
Objectives

• Motivate for requirement analysis
• Introduce the general analysis process
• Requirements elicitation
• Developing prototypes
• Creating analysis models
• Producing a requirements specification
• Identify key principles that are applied to
  analysis

3
Definition of requirements
Requirements definition is the process that
determines the properties a particular system
should have. The requirements process generates
the information on which the design will be
based. You have to know where the system is to be
used, by whom, and what services it should
provide. The parties participating in the
requirements definition process are referred to
as stakeholders. If the customer is known, the
requirements may be the basis for the development
contract. If it is unknown, the marketing
organization may assume this function.
4
No Formal Customer Requirements

• Recipe for disaster
• The customer has only a vague idea of what is
  required
• The developer is willing to proceed with the
  vague idea on the assumption that well fill
  in the details as we go
• Repeat
• Customer keeps changing requirements
• Developer is ratcheted by these changes, making
  errors in specifications and development
• Until the project flops

5
Why are requirements important?
Top factors of the causes of failed projects
(over 8000 projects) 13.1 incomplete
requirements 12.4 lack of user
involvement 10.6 lack of resources 9.9 unreal
istic expectations 9.3 lack of executive
support 8.7 changing requirements and
specifications 8.1 lack of planning
6
Aspects of reqirements

• The requirements identify the WHAT of the system,
  the design identifies the HOW.
• From customers view there are three types of
  requirements
• That absolutely must be met
• That are highly desirable but not necessary
• That are possible but could be eliminated

7
More on requirements
Requirements can be functional, describing
interactions between the system and its
environment and describing the systems behaviour
given certain stimuli, and non-functional,
describing a resctriction on the system that
limits our choices for constructing the solution
to the problem. The domain requirements are
derived from the application domain and describe
system characteristics and features that reflect
the 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
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 contradictions in
  the descriptions of the system facilities
• In practice, it is very difficult or impossible
  to produce a complete and consistent requirements
  document

10
Non-functional requirements

• 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

11
Non-functional requirement types
12
Requirements measures
13
Requirements interaction

• Conflicts between different non-functional
  requirements are common in complex systems
• Spacecraft system
• To minimise weight, the number of separate chips
  in the system should be minimised
• To minimise power consumption,
• lower power chips should be used
• However, using low power chips
• may mean that more chips have
• to be used.
• Which is the most critical requirement?

14
Domain requirements problems

• Understandability
• Requirements are expressed in the language of the
  application domain
• This is often not understood by software
  engineers developing the system
• Implicitness
• Domain specialists understand the area so well
  that they do not think of making the domain
  requirements explicit

15
Types of 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 services. Written as a
  contract between client and contractor
• Software specification
• A detailed software description which can serve
  as a basis for a design or implementation.
  Written for developers

16
Requirement readers
17
User requirements

• Should describe functional and non-functional
  requirements so that they are understandable by
  system users who dont have detailed technical
  knowledge
• User requirements are defined using natural
  languages, tables and diagrams

18
System requirements and specifications

• More detailed specifications of user requirements
• Serve as a basis for designing the system
• May be used as part of the system contract
• System requirements may be expressed using system
  models (will be discussed later)

19
Requirement docs.
The requirements definition and specification
documents describes the following kinds of
items Physical environment. Where is the
equipment to function? Is there one location or
several? Are there any environmental
restrictions, such as temperature, humidity, or
magnetic interference? Interfaces. Is the input
coming from one or more other systems? Is the
output going to one or more other systems? Is
there a prescribed way in which the data must be
formatted? Is there a prescribed medium that the
data must use?
20
Requirement docs. cont.
Users and Human factors. Who will use the system?
Will there be several types of users? What is the
skill level of each type of user? What kind of
traning will be required for each type of user?
How easy will it be for a user to understand and
use the system? How difficult will it be for a
user to misuse the system? Functionality. What
will the system do? When will the system do it?
Are there several modes of operation? How and
when can the system be changed or enhanced? Are
there constraints on execution, speed, response
time or throughput?
21
Requirement docs cont.
Documentation. How much documentation is
required? Should it be on-line, in book-format or
both? To what audience is each type of
documentation addressed? Data. For both input and
output, what should the format of the data be?
How often will they be received or sent? How
accurate must they be? To what degree of
precision must the calculations be made? How much
data flow through the system? Must any data be
retained for any period of time? Resources. What
materials, personnel, or other resources are
required to build, use, and maintain the system?
What skills must the developers have? How much
physical space will be taken up by the system?
22
Requirement docs cont.
What are the requirements for power, heating, or
air conditioning? Is there a prescribed timetable
for development? Is there a limit on the amount
of money to be spent on the development or on
hardware and software? Security. Must access to
the system or to information controlled? How will
one users data be isolated from others? How will
user programs be isolated from other programs and
from the operating system? How often will the
system be backed up? Must the backup copies be
stored at a different location? Should
precautions be taken against fire, water damage,
ot theft?
23
Requirements docs cont.
Quality assurance. What are the requirements for
reliability, availability, maintainability,
security, and other quality attributes? How must
the characteristics of the system be
demonstrated? Must the system detect and isolate
faults? What is the prescribed mean time between
failures? How can the system incorporate changes
to the design? Will maintainance merely correct
errors or will it also include improving the
system? What efficiency measures will apply to
resource usage and response time? How easy should
it be to move the system from one location to
another or from one type of computer to another?
24
Software Requirements Analysis

• Identify the customer and work together to
  negotiate product-level requirements
• Build an analysis model (warning not
  object-oriented)
• focus on data
• define function
• represent behavior
• Prototype areas of uncertainty
• Develop a specification (semi-formal contract
  between customer and developers) that will guide
  design
• Conduct formal technical reviews

25
The Analysis Process
26
Sources of Requirements
build a prototype
require. elicitation
develop spec.
Review
analysis models

• Elicit requirements from
• Stakeholdes wants and needs
• Domain models
• Current situation model
• Reusable requirements //Reuse library//
• Suggested types of requirements //requirements
  template//
• Existing documents

27
Requirements Elicitation

• Communicate with the customer(s) to elicit the
  requirements of the system
• Informal approach - meetings and interviews
• Ask questions
• Context who is behind the request for this
  work?, who will use the solution?, Is there
  another source for the solution?
• Specific What problems will this solution
  address?, What are the performance issues or
  constraints?
• Meta-questions Are you the right person to
  answer these questions?, Should I be asking you
  anything else?
• BUT really only good for the initial meeting
• Problem customers communicate wants not needs
• Other structured approaches FAST, QFD,
  Use-Cases, questionnaires.

28
How users and developers see each other
How developers see users. Users dont know what
they want. Users have too many needs. Users want
everything right now. Users cant prioritize
needs. Users refuse to take responsibility for
the system. Users are unwilling to compromise.
Users cant remain on schedule. How users see
developers. Developers dont understand
operational needs. D place too much emphasis in
technicalities. Developers try to tell us how to
do our jobs. D cant translate clearly stated
needs into a succesful system. D say no all the
time. D are always over budget. D are always
late. D are unable to respond quickly to
legitimately changing needs.
29
Facilitated Application Specification Techniques
(FAST)

• Overcome the us and them
  mindset of
• developers
  
• and customers
• Create a joint team of customers and
  developers that work
  together to
• Identify the problem
• Propose elements of the solution
• Negotiate different approaches
• Specify a preliminary set of solution
  requirements

Software
Customer
Engineers
Group
Group
30
FAST Guidelines

• Meetings have a specific structure
• Rules for preparation and participation
• A facilitator and definition mechanism
• Predominantly implemented as Joint Application
  Development (JAD)
• Rules
• participants must attend the entire meeting
• all participants are equal
• preparation is as important as meeting
• pre-meeting documents are to be viewed as
  proposed
• off-site meeting location is preferred
• set an agenda and maintain it
• dont get mired in technical detail
• www.bee.net/bluebird

31
Quality Function Deployment

• Quality management technique that ranks customer
  requirements as
• Normal requirements if these are present the
  customer is satisfied
• Expected requirements often implicit, absence
  will cause much wailing and gnashing of teeth
• Exciting requirements above and beyond the
  users expectations
• Components
• Function deployment determines the value (as
  perceived by the customer) of each function
  required of the system
• Information deployment identifies data objects
  and events
• Task deployment examines the behavior of the
  system
• Value analysis determines the relative ranking of
  requirements
• www.qfdi.org

32
Use-Cases

• A collection of scenarios that describe the
  thread of usage of a system
• Each scenario is described from the point-of-view
  of an actor
• Role is a better word
• A person or device that interacts with the
  software in some way
• Each scenario answers the following questions
• What are the main tasks or functions performed by
  the actor?
• What system information will the actor acquire,
  produce or change?
• Will the actor inform the system about
  environmental changes?
• What information does the actor require of the
  system?
• Does the actor wish to be informed about
  unexpected changes?
• members.aol.com/acockburn/papers/OnUseCases.htm

33
Prototypes
build a prototype
require. elicitation
develop spec.
Review
analysis models

• If the requirements are uncertain then consider
  prototyping during analysis
• Build a prototype ? Show it to the customers ?
  Adapt it to their needs
• Features
• Rapid (gloss over imperfections, ignore design
  issues)
• Built for change (will have to undergo quick
  iterations)
• Throwaway (must not live beyond requirements
  phase)
• Invaluable for mock-ups of the user interface

34
Pros and Cons of Prototyping

• Warning label
• Do not use the prototype as the legal
  specification document
• Do not develop the prototype into the product
  (good to code it in a different language from the
  main development)
• Case Studies Report
• Enthusiastic reception from users
• Improved usability of final software
• 2/3 of the study didnt discard the prototype
• Prototyping might lead to unfortunate user
  expectations about change
• The prototype can be retained as long as it
  undergoes rigorous design and quality assurance.
  But this defeats the purpose of prototyping

35
Selecting the appropriate prototyping approache
36
Create Analysis Models
build a prototype
require. elicitation
develop spec.
Review
analysis models
37
Analysis Principles

• Focus on the essence of the problem (no
  implementation details)
• Examine what rather than how
• Understand the problem before you begin to create
  the analysis model
• Develop prototypes that enable a user to
  understand how human-machine interaction will
  occur
• Record the origin of and the reason for every
  requirement
• Use multiple views of requirements
• Prioritize requirements
• Work to eliminate ambiguity (primary advantage of
  Formal Mathematical Specification)

38
Functional Models

• Data
• define data objects, attributes and relationships
• traditionally use Entity Relationship diagrams
• Function
• identify functions that transform data objects
• indicate how data flows through the system
• represent producers and consumers of data
• traditionally use Data and Control Flow Diagrams
• Behaviour
• indicate different states of the system
• specify events that cause the system to change
  state
• traditionally use State Transition Diagrams

39
Object Oriented Models

• Most OOD processes have the following steps in
  common
• Elicit customer requirements
• Identify scenarios or use-cases
• Extract candidate classes
• Identify attributes and methods
• Define a class hierarchy
• Build an object-relationship model
• Build an object-behaviour model
• Review the OO analysis against the use-cases
• Repeat as required

40
Unified Modelling Language

• A notational System (including syntax, semantics
  and pragmatics for its notations) that is
  principally graphical and aimed at modelling
  systems using object-oriented concepts.
• UML is not a process or methodology, it is
  standardized by the OMG (Object Management Group)
• Defines a notation and a meta-model (defining the
  notation using the notation)
• Consists of
• Views (shows different faces of the system and
  links with the process, e.g. user, structural,
  behavioural, etc.)
• Diagrams (graphs that describe the contents of a
  view)
• Model elements (concepts used in a diagram)

41
UML
UML can be used to visualize, specify, or
document a problem. UML diagrams include the
static view, the dynamic view of the system, plus
restrictions, formalizations. The dynamic view is
depicted with use cases (Use Case D), list of
activities (Activity D), interaction diagrams
showing sequences (how messages flow from one
object to another - Sequence D), and
collaboration (flow of events between objects
Collaboration D), and state machines to
illustrate states and their changes (State D).
The static view is depicted with Class Diagrams,
showing relationships and extensibility, and
shows packages and deployment (Package D,
Deployment D, Component D). Restrictions and
formalization are expressed with OCL.
42
Requirements Spec.
build a prototype
require. elicitation
develop spec.
Review
analysis models

• End product of analysis
• The requirements specification is the official
  statement of what is required of the system
  developers
• Should include both a definition and a
  specification of requirements
• It is NOT a design document. As far as possible,
  it should set out WHAT the system should do
  rather than HOW it should do

43
Users of the Requirements Spec.
Specify the requirements and read them to check
that they meet their needs. They specify changes
to the requirements.
System Customers
Use the requirements document to plan a bid for
the system and to plan the system development
process
Managers
Use the requirements to understand what system is
to be developed
System Engineers
System Test Engineers
Use the requirements to develop validation tests
for the system
Use the requirements to help understand the
system and the relationship between its parts
System Maintenance Engineers
44
Properties of the Specification

• Separate functionality from implementation
• Specify external system behaviour
• Specify implementation constraints
• Be easy to change
• Serve as reference tool for maintenance
• Record forethought about the life cycle of the
  system
• Characterize responses to unexpected events
• Recognize that the specification must be
  tolerant of incompleteness and augmentation

45
Spec Structure

• Introduction set out goals, objectives and
  context of the software
• Information Description document data content,
  flow and structure
• Functional Description A description of the
  functions required to solve the problem
• Behavioural Description operation of the
  software as a result of internal and external
  events
• Validation Criteria often overlooked, how is a
  successful implementation going to be recognized
• Bibliography and Appendix reference to related
  documents, definition of terms, graphical models

46
Requirements Review
build a prototype
Review
require. elicitation
develop spec.
analysis models

• This is conducted by both customers and
  developers
• Once complete the Software Requirements
  Specification document is signed off by the
  customer and developer
• But Spec is difficult to test in a meaningful way

47
What does the requrement review entail?

• Review the stated goals and objectives of the
  system.
• Compare the requirements with the goals and
  objectives to verify that all requirements are
  necessary.
• Describe the environment in which the system is
  to operate. Examine the interfaces between the
  system and all other systems, and verify that
  they are correct and complete (then information
  flow, structure reviewed). Review the functions
  of the system regarding consistency, scope and
  intention of the customer. (they should be
  realistic within the development abilities) Check
  all the requirements against omission,
  incompleteness and inconsistency.

48
What does the req. review entail 2
4. Assess and document the risks, if it is
involved in the development or in actual
functioning of the system. Discuss and compare
alternatives. The developers and customers must
agree on the approaches to be used. 5. Talk about
testing the system. How will the requirements
continue to be verified and validated as
development progresses? How will the test team
test to see that all requirements have been
implemented properly? Who will provide the test
data? If the system is to have a phased
implementation, how will the requirements be
checked during the intermediate phases?
49
How to express requrements? problems with
natural languages

• Lack of clarity
• Precision is difficult without making the
  document difficult to read
• Requirements confusion
• Functional and non-functional requirements tend
  to be mixed-up
• Requirements amalgamation
• Several different requirements may be expressed
  together

50
How to express requirements? other methods
Static description. Expression as a language,
e.g. BNF Data abstraction (ERD) Dynamic
description Decision tables, Event-tables Abstr
act State Machine Language (ASML) Data and
control flow diagram (DFD, CFD) State transition
diagram (STD) Specification Description Language
(SDL),
51
How to express requirements?
Others Software Requirements Engineering
Methodology (SREM), Requirement Statement
Language (RSL) Formal languages
52
How to express requirements?
Program Description Language (PDL) Structured
Analysis and Design Technique (SADT, US Dept. Of
Defense) OO technics (UML) Object Process
Methodology (OPM)
53
Evaluating spec. Methods 1.
Applicability. Can the technique describe
real-world problems and solutions in a natural
and realistic way? Are the techniques
assumptions are reasonable? Is the technique
compatible with the other techniques that will be
used on the project? Implementability. Can the
specification be refined or translated easily
into an implementation? How difficult is the
translation? Is it automated? If code is
generated automatically from the specification,
is the generated code efficient? Is there a
clean, well-defined interface between the
machine-generated code and the manually-generated
code and the manually-generated portions of the
implementation?
54
Evaluating spec. Methods 2.
Testability/Simulation. Can the specification be
used to test the implementation? Is every
statement in the specification testable by the
implementation? Is it possible to execute the
specifitation? Checkability. Can someone who
understands the underlying problem being solved
check the specification accuracy? Are the
specifications readable by domain experts? Are
there automated specification checkers? Maintainab
ility. Will the specification be useful for
maintanance activities? Is it easy to change the
specification as the system evolves?
55
Evaluating spec. Methods 3.
Modulatity. Does the method allow a large
specification to be decomposed into smaller parts
that are more easily understood? Can changes be
made to the smaller parts without rewriting the
entire specification? Level of abstraction/express
ibility. From the user point of view, how closely
and expressively can the specification elements
describe the actual objects, actions and
environment in the user domain? Soundness. Can we
detect inconsistencies or ambiguities in the
specification? Are the semantics of the
specification language defined precisely?
56
Evaluating spec. Methods 4.
Verifiability. Can we demonstrate formally that
the specification satisfies the properties stated
at each level of abstraction? Can the
verification process be automated, and, if so, is
the automation easy? Run-time safety. If code can
be generated automatically from the
specification, does the code degrade gracefully
under unexpected conditions? Tools maturity. For
any tools supporting the specification technique,
are they of high quality? Is there training
available for learning to use them? What is the
size of the user base for the tools?
57
Evaluating spec. Methods 5.
Looseness. Can the specification be incomplete or
admit nondeterminism? Learning curve. Can a new
user learn quickly the techniques concepts,
syntax, semantics, and heuristics? Technique
maturity. Has the technique been defined or
standardized? Is there a user group or large user
base? Data modeling. Does the technique represent
data, relationships, or abstractions? Are the
representation integrated? Discipline. Does the
technique force its users to write
well-understood, understable, and well-behaved
specifications?
58
Requirements evolution

• Requirements change rapidely during requirements
  elicitation. Tool for managing requirements
• RequisitPro from Rational
• Stores requirements in a repository
• Multi-user access
• Automatically creates a requirements document
  from the repository
• Provides traceability and change management
  throughout the project lifecycle
• www.rational.com/products/reqpro/docs/datasheet.ht
  ml

59
Key Points

• Requirements set out what the system should do
  and define constraints on its operation and
  implementation
• Functional requirements set out services the
  system should provide
• Non-functional requirements constrain the system
  being developed or the development process
• User requirements are high-level statements of
  what the system should do

60
Key Points

• User requirements should be written in natural
  language, tables and diagrams
• System requirements are intended to communicate
  the functions that the system should provide
• System requirements may be written in structured
  natural language or in a formal language
• A software requirements document is an agreed
  statement of the system requirements