Developing Requirements

1
Developing Requirements

• Before software can be designed , its
  requirements must be well understood.
• Before requirements can be expressed, the
  application domain must be similarly well
  understood.

2
Example

• Outline in one paragraph the information you
  would need to gather in order to perform domain
  analysis for the airline reservation system.

3
Domain Analysis

• The process by which a software engineer learns
  about the domain to better understand the
  problem
• The domain is the general field of business or
  technology in which the clients will use the
  software
• A domain expert is a person who has a deep
  knowledge of the domain
• Benefits of performing domain analysis
• Faster development
• Better system
• Anticipation of extensions

4
The Starting Point for Software Projects
green field project
5
Defining the Problem and the Scope

• A problem can be expressed as
• A difficulty the users or customers are facing,
• Or as an opportunity that will result in some
  benefit such as improved productivity or sales
• The solution to the problem normally will entail
  developing software
• A good problem statement is short and succinct

6
Defining the Scope

• Narrow the scope by defining a more precise
  problem
• List all the things you might imagine the system
  doing
• Exclude some of these things if too broad
• Determine high-level goals if too narrow

7
Example

• A university registration system

8
Example

• Define the problem and scope for a system that
  handles university degree requirements and
  registrations
• Fee payments and related accounting and billing
• Applications for admission
• Editing and querying the list of available
  courses, including their descriptions and lists
  of prerequisites
• Editing and querying the requirements for
  obtaining a degree
• Editing and querying the list of courses to be
  taught in a given semester
• Scheduling the times that courses will be offered
• Allocating courses or exams to rooms
• Helping students determine which courses they
  could take by analyzing their degree
  requirements, the courses they have previously
  taken, their schedule, and their preferences
• Registering students
• Recording marks
• Printing transcripts

9
Example

• You are asked to improve a data entry program
  used to enter a patients personal information
  when he or she is first admitted to a hospital.
  Admission clerks have to enter each new patients
  name, address, telephone number, and various
  other pieces of data. The customer tells you that
  the admissions clerks make an unacceptable number
  of mistakes that contaminate the database and
  cause administrative problems. You are told that
  the problem is lack of clarity in the user
  interface, which leads the clerks to put
  information in the wrong places. What, however,
  is the real problem and how might understanding
  this affect potential solutions?

10
Example

• This is the inverse of the last example. This
  time, you are told by the customer that the
  problem is, the data-entry system is not
  high-tech enough. Hence you are asked to write
  a system that scans drivers licenses and other
  documents in order to enter a new patients name
  and address accurately and quickly. What mistake
  could you be making if you accept this problem
  statement and proceed to do exactly what the
  customer asks?

11
What is a Requirement ?

• It is a statement describing either
• 1) an aspect of what the proposed system must do,
  
• or 2) a constraint on the systems development
• In either case it must contribute in some way
  towards adequately solving the customers problem
• the set of requirements as a whole represents a
  negotiated agreement among the stakeholders
• A collection of requirements is a requirements
  document

12
Functional Requirements

• What inputs the system should accept
• What outputs the system should produce
• What data the system should store that other
  systems might use
• What computations the system should perform
• The timing and synchronization of the above

13
Requirements Document

• Each functional requirement is given in the
  following format
• Index
• Name
• Purpose
• Input parameters
• Action
• Output parameters
• Exceptions
• Remarks
• Cross-references

14
A Requirements Engineering Process

• Requirement Engineering Process
• 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
• Requirements identification
• Requirements analysis
• Requirements specification
• Requirement validation
• Needed for complex, large, or critical problems

15
Requirements problems

• The requirements dont reflect the real needs of
  the customer for the system.
• Requirements are inconsistent and/or incomplete.
• It is expensive to make changes to requirements
  after they have been agreed.
• There are misunderstandings between customers,
  those developing the system requirements and
  software engineers developing or maintaining the
  system

16
The need for a proper RE process

• Without a proper requirements engineering
  process
• Projects go over budget and/or take longer time
  than first predicted
• People involved in system analysis complain that
  they do not have enough time or resources to do
  their job properly
• Requirements documents are often not
  understandable or incomplete
• The system design process suffers from rework due
  to requirements errors or incompleteness
• Resulting systems lack some functionalities or
  have unused functionalities
• System maintenance costs goes skyrocket
• The cost of system changes/improvement is hard to
  evaluate

17
RE process - inputs and outputs
18
Input/output description
19
Stakeholders in the RE process

• Stakeholders in a process are the people involved
  in the execution of that process
• They are normally identified by their roles
  rather than individually
• Requirements engineering involves actors who are
  primarily interested in the problem to be solved
  (end-users, etc) as well actors interested in the
  solution (system designers, etc.)

20
Types of stakeholder

• Software engineers responsible for system
  development
• System end-users who will use the system after it
  has been delivered
• Managers of system end-users who are responsible
  for their work
• External regulators who check that the system
  meets its legal requirements
• Domain experts who give essential background
  information about the system application domain

21
Human and social factors

• Requirements engineering processes are dominated
  by human, social and organizational factors
  because they always involve a range of
  stakeholders from different backgrounds and with
  different individual and organizational goals.
• System stakeholders may come from a range of
  technical and non-technical background and from
  different disciplines

22
Factors influencing requirements

• Personality and status of stakeholders
• The personal goals of individuals within an
  organization
• The degree of political influence of stakeholders
  within an organization

23
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 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

24
System requirements versus Software requirements

• System requirements include constraints and
  capabilities of the entire product including
  hardware and software.
• Software requirements form a subset of system
  requirements.
• System requirements are mostly constrained by
  organizational policies and environment.
• Software requirements may or may not be
  constrained by organizational policies.

25
Customer requirements Vs Developer requirements

• Requirements given by customers are mandatory
  requirements
• Must be captured in the product
• Requirements that are introduced by developers to
  support customers expectations are called
  developer requirements
• Support design activities
• Preferences
• Consequences of other requirements

26
Developer requirements are different from design
issues

• Developer requirements must still describe only
  WHAT of the problem, but not HOW.
• Requirements must not dictate HOW to develop the
  product.
• Developer requirements may arise from system
  constraints, limitations and other conditions
  that were imposed by the environment.

27
Example

• Customer requirement
• Data must be stored in files, and no external
  database will be used.
• Developer requirement
• Data must be stored in indexed sequential files
  because of the success in using this type of
  files in previous projects

28
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.

29
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 also
  functional system requirements should describe
  the system services in detail

30
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 accounts permanent storage
  area.

31
Requirements imprecision

• 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

32
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 / impossible to
  produce a complete and consistent requirements
  document

33
Nonfunctional Requirements Purpose

• Define the qualitative aspects of requirements
• May restrict the design and implementation
• May restrict the process and/or the product
• May arise due to
• standards
• organizational policies
• interoperability constraints

34
Distinction between functional and non-functional
requirements

• The system shall ensure that data is protected
  from unauthorized access
• Non-functional requirement (Security)
• The system shall include a user authorization
  mechanism through ltlogin, passwordgt only users
  with registered login id and valid password can
  use the system
• Functional requirement
• not arising from the application domain
• May be a developer requirement

35
Classifications of non-functional requirements

• Some from IEEE Std 830-1993
• Interface requirements (interoperability
  constraints)
• Security requirements (user authorization
  constraints)
• Portability requirements (system usage
  constraints)
• Reliability requirements
• Safety requirements
• Documentation requirements (Standards
  constraints)
• Acceptance requirements (Standards constraints)

36
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

37
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.

38
Non-functional requirement types
39
Product Requirements Some examples

• System shall have an availability of 99
• Reliability requirement
• System must respond back within 5 seconds
• Performance requirement
• Executable code of the system shall not exceed
  0.5 MB
• Capacity requirement
• System shall be installed on PC, Mac and UNIX
  stations
• Portability requirement

40
Conflicting product requirements Some examples

• System shall respond back within 5 seconds
• System shall have an availability of 99
• May not be achievable if the response time is too
  short
• System shall use the Gnu C compiler
• May result in a portable code but may not be
  efficient, and hence may not satisfy performance
  requirement
• Conflicting requirements need negotiation between
  customers and developers
• Often discovered later in the development cycle

41
Organizational Requirements Some examples

• Also called Process requirements
• System shall conform to IEEE Standards for
  processes
• Standards requirement
• System shall use Rational Rose for developing the
  design diagrams and code generation
• Implementation constraint
• Not preferred during requirements engineering
  process, but organizational policy may restrict
  the use of any other tool

42
External requirements some examples

• The system output must be certified for format
  and contents by the chief medical officer
• Legislation constraint
• The braking subsystem must conform to the
  standards defined by Professional Society of
  Engineers
• This particular standard may describe hardware
  design issues only, but the control system must
  take into account the standards requirement
• External requirements are generally hard to
  achieve

43
Non-functional requirements

• Concerned with qualitative aspects of the
  software product
• Reliability
• Maintainability
• Security
• Portability
• SRS may include a set of non-functional
  requirements as expected by the customer(s)
• May also include developer requirements to
  support and to justify how to achieve these
  non-functional requirements

44
Relationship between user needs and
non-functional requirements
45
Non-functional Requirements measures
46
Non-functional 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?

47
Exercise

• Classify the following aspects of an airline
  reservation system into F for functional, NF
  for non-functional and X for should not be a
  requirement.
• How information about flights, passengers and
  booking are entered
• What Information appears on tickets and reports
• How fares are calculated
• What information must be stored in the database
  that travel agents and others access
• The system should be designed so it can be
  extended to handle a frequent flier plan
• The system must be available at all times. Only 2
  minutes downtime a week is to be permitted
• A merge sort algorithm must be used to sort the
  flights by departure time

48
Requirements analysis

• A process by which requirements are categorized,
  organized into groups and explored for
  relationships with other requirements
• Main focus is for consistency, ambiguities and
  omissions
• Preferences and ranking among requirements are
  identified

49
Some guidelines for requirements analysis

• Identify and remove inconsistencies
• no two requirements contradict with each other
• mathematical analysis is ideal, but hard to
  perform
• often done using requirements analysis experts
• Identify and remove ambiguities
• a requirement is ambiguous if there is more than
  one interpretation for the same requirement
• ambiguities can be removed by checking with the
  customers

50
Some guidelines for requirements analysis
(continued)

• Check for the relevance of each requirement to
  the goal or objective of the end product
• unnecessary and redundant requirements can be
  removed
• Check whether each requirement is implementable,
  verifiable or testable
• the quality assurance team will generally confirm
  this check for each requirement

51
Ambiguous Statements

• I know you believe you understood what you think
  I said, but I am not sure you realize that what
  you heard is not what I meant.
• The son of an American Airlines pilot who died in
  the San Diego air crash said he already knew
  about this.
• A New York Businessman is taking his campaign to
  coax people to give up their guns to gang-ridden
  Los Angeles.

52
Ambiguous statement in requirements

• The new number is first placed in the last
  position of the array and then compared with the
  previous number. If it is greater, then the two
  are interchanged.
• Corrected
• The new number n is first placed in the last
  position of the array and then compared with the
  number p in the previous position of the array.
  If n is greater, then n and p are interchanged.

53
Ambiguous statement in requirements

• when the user selects an aircraft, the system
  assigns it to the flight

54
Statements in requirements that lead to design
errors

• Telecommunication system example
• One requirement to create a password says
• The user can choose any sequence of six keys on
  the telephone receiver as the password
• Another requirement says
• Enter the password (must be six characters) and
  then press the pound () key
• Not possible to correct the password at this
  stage because the user has not entered into the
  system

55
Another example

• A table with four values in each row
• One requirement says
• Enter the four values given in the input into a
  new row. If any of the values is not specified in
  the input, leave that column in the table empty.
• Another requirement says
• The value in the first column is the key. If, for
  a given key a match is found, then the second and
  fourth values are multiplied and the result is
  output.
• What happens if the value is empty?

56
One more example

• A security system
• One requirement says
• If condition C is violated, an alarm must be
  raised and the system must be shut down
  immediately.
• Another requirement says
• When an alarm is raised, the sensor S must be
  activated to close the door.
• How can S be activated when the system is shut
  down?

57
Exercise

• Review the following short statement of
  functional requirements for a restaurant advisor
  system, point out any problems you find.
• This system will allow people to choose a
  restaurant in a city. Users enter one or more of
  the following criteria, and then the system
  searches its database for suitable restaurants
  food type, price range, neighborhood, size,
  service type (fast food, cafeteria, buffet, full
  service), smoking arrangements (none allowed,
  separately ventilated section, non-separately-vent
  ilated section). The user can also specify a
  desired day and time-period, and the number of
  people in their party. The system will tap into
  the reservation database( of participating
  restaurants) and only display restaurants that
  have available space. After entering the
  criteria, the user clicks on search, and the
  system displays a list of matching restaurants.
  For restaurants that participate in the automated
  reservation system, the user can click on
  reserve next to a selection in order to make a
  reservation.

58
Some Techniques for Gathering and Analysing
Requirements

• Observation
• Read documents and discuss requirements with
  users
• Shadowing important potential users as they do
  their work
• ask the user to explain everything he or she is
  doing
• Session videotaping
• Interviewing
• Conduct a series of interviews
• Ask about specific details
• Ask about the stakeholders vision for the future
  
• Ask if they have alternative ideas
• Ask for other sources of information
• Ask them to draw diagrams

59
Gathering and Analysing Requirements

• Brainstorming
• Appoint an experienced moderator
• Arrange the attendees around a table
• Decide on a trigger question
• Ask each participant to write an answer and pass
  the paper to its neighbour
• Joint Application Development (JAD) is a
  technique based on intensive brainstorming
  sessions

60
Gathering and Analysing Requirements

• Prototyping
• The simplest kind paper prototype
• a set of pictures of the system that are shown to
  users in sequence to explain what would happen
• The most common a mock-up of the systems UI
• Written in a rapid prototyping language
• Does not normally perform any computations,
  access any databases or interact with any other
  systems
• May prototype a particular aspect of the system

61
Gathering and Analysing Requirements

• Use case analysis
• Determine the classes of users that will use the
  facilities of this system (actors)
• Determine the tasks that each actor will need to
  do with the system

62
Use-Cases describing how the user will use the
system

• A use case is a typical sequence of actions that
  a user performs in order to complete a given task
• The objective of use case analysis is to model
  the system from the point of view of
• how users interact with this system
• when trying to achieve their objectives.
• It is one of the key activities in requirements
  analysis
• A use case model consists of
• a set of use cases
• an optional description or diagram indicating how
  they are related

63
Use cases

• A use case should
• Cover the full sequence of steps from the
  beginning of a task until the end
• Describe the users interaction with the system
• Not the computations the system performs
• Be written so as to be as independent as possible
  from any particular user interface design
• Only include actions in which the actor interacts
  with the computer
• Not actions a user does manually

64
Scenarios

• A scenario is an instance of a use case
• A specific occurrence of the use case
• a specific actor ...
• at a specific time ...
• with specific data.

65
How to describe a single use case

• A. Name Give a short, descriptive name to the
  use case
• B. Actors List the actors who can perform this
  use case
• C. Goals Explain what the actor or actors are
  trying to achieve
• D. Preconditions State of the system before the
  use case
• E. Summary Give a short informal description
• F. Related use cases
• G. Steps Describe each step using a 2-column
  format
• H. Postconditions State of the system in
  following completion
• A and G are the most important

66
Use case diagrams
67
Extensions

• Used to make optional interactions explicit or to
  handle exceptional cases.
• Keep the description of the basic use case simple.

68
Generalizations

• Much like superclasses in a class diagram.
• A generalized use case represents several similar
  use cases.
• One or more specializations provides details of
  the similar use cases.

69
Inclusions

• Allow one to express commonality between several
  different use cases
• Are included in other use cases
• Even very different use cases can share sequence
  of actions
• Enable you to avoid repeating details in multiple
  use cases
• Represent the performing of a lower-level task
  with a lower-level goal

70
Example of generalization, extension and inclusion
71
Example description of a use case
72
Example (continued)
73
Example (continued)
74
Example (continued)
75
Example (continued)
76
Exercise

• You are developing a system for managing the
  processes of a small town public library. List
  all the actors for this system.

77
Exercise

• List a minimal set of use cases for the following
  actors in a library system Borrower, Checkout
  Clerk, Librarian, Accounting System

78
Choosing use cases on which to focus

• Often one use case (or a very small number) can
  be identified as central to the system
• The entire system can be built around this
  particular use case
• There are other reasons for focusing on
  particular use cases
• Some use cases will represent a high risk because
  for some reason their implementation is
  problematic
• Some use cases will have high political or
  commercial value

79
The benefits of basing software development on
use cases

• They can
• Help to define the scope of the system
• Be used to plan the development process
• Be used to both develop and validate the
  requirements
• Form the basis for the definition of test cases
• Be used to structure user manuals

80
Use cases must not be seen as a panacea

• The use cases themselves must be validated
• Using the requirements validation methods.
• Some aspects of software are not covered by use
  case analysis.
• Innovative solutions may not be considered.

81
Types of Requirements Document
Two extremes An informal outline of the
requirements using a few paragraphs or simple
diagrams A long list of specifications that
contain thousands of pages of intricate detail

• Requirements documents for large systems are
  normally arranged in a hierarchy

Requirements
Requirements
Definition
Definition
xxxx
xxxx
xxxxxxx
xxxxxxx
Requirements
xxx
Requirements
xxx
Requirements
xxxxxxxxxxx
xxxxxxxxxxx
Specification
Specification
xxxxx
Specification
xxxxx
xxxx
xxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxx
xxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxx
xxx
xxx
xxx
xxx
xxxxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxx
xxxxx
xxxxx
xxxxx
xxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxx
xxx
xxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
82
Level of detail required in a requirements
document

• How much detail should be provided depends on
• The size of the system
• The need to interface to other systems
• The readership
• The stage in requirements gathering
• The level of experience with the domain and the
  technology
• The cost that would be incurred if the
  requirements were faulty

83
Requirements documents

• The document should be
• sufficiently complete
• well organized
• clear
• agreed to by all the stakeholders
• Traceability

84
Managing Changing Requirements

• Requirements change because
• Business process changes
• Technology changes
• The problem becomes better understood
• Requirements analysis never stops
• Continue to interact with the clients and users
• The benefits of changes must outweigh the costs
• Certain small changes (e.g. look and feel of the
  UI) are usually quick and easy to make at
  relatively little cost
• Larger-scale changes have to be carefully
  assessed
• Forcing unexpected changes into a partially built
  system will probably result in a poor design and
  late delivery
• Some changes are enhancements in disguise
• Avoid making the system bigger, only make it
  better

85
Difficulties and Risks in Domain and Requirements
Analysis

• Lack of understanding of the domain or the real
  problem
• Do domain analysis and prototyping
• Requirements change rapidly
• Perform incremental development, build
  flexibility into the design, do regular reviews
• Attempting to do too much
• Document the problem boundaries at an early
  stage, carefully estimate the time
• It may be hard to reconcile conflicting sets of
  requirements
• Brainstorming, JAD sessions, competing prototypes
  
• It is hard to state requirements precisely
• Break requirements down into simple sentences and
  review them carefully, look for potential
  ambiguity, make early prototypes

86
Methods for requirements analysis

• Informal approach
• walk through the requirements document and try to
  identify as much errors as possible
• these errors include inconsistencies and
  ambiguities
• Diagrammatic approach
• use diagrammatic notations to rewrite the
  requirements and analyze the diagrams
• Formal approach
• use a formal specification language to rewrite
  the requirements and analyze them using the
  semantics of the formal specification language as
  the basis

87
Key points

• Requirements set out what the system should do
  and define constraints on its operation and
  implementation
• A software requirements document is an agreed
  statement of the system requirements
• 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