Developing Requirements - PowerPoint PPT Presentation

Loading...

PPT – Developing Requirements PowerPoint presentation | free to download - id: 152fb4-NWEyZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Developing Requirements

Description:

... to gather in order to perform domain analysis for the airline reservation system. ... How fares are calculated ... of an American Airlines pilot who died in ... – PowerPoint PPT presentation

Number of Views:112
Avg rating:3.0/5.0
Slides: 88
Provided by: maoz4
Learn more at: http://www.cs.uwlax.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com