Lecture 5: Requirements Engineering - PowerPoint PPT Presentation

Loading...

PPT – Lecture 5: Requirements Engineering PowerPoint presentation | free to view - id: 21f023-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Lecture 5: Requirements Engineering

Description:

A requirement is a feature of the system or a description of something the ... Some Reasons for Incompleteness. Requirements can be interpreted differently. ... – PowerPoint PPT presentation

Number of Views:31
Avg rating:3.0/5.0
Slides: 26
Provided by: plekhanova
Category:

less

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

Title: Lecture 5: Requirements Engineering


1
Lecture 5 Requirements Engineering
  • Dr Valentina Plekhanova
  • University of Sunderland, UK

http//www.cet.sunderland.ac.uk/cs0vpl/SE-Com185.
htm
2
What is a Requirement? Pfleeger, 1998
  • A requirement is a feature of the system or a
    description of something the system is capable of
    doing in order to fulfil the systems purpose.

3
What is a Requirement?
  • It may range from a high-level abstract statement
    of a service or of a system constraint to a
    detailed mathematical functional specification.
  • May be the basis for a bid for a contract -
    therefore must be open to interpretation.
  • May be the basis for the contract itself -
    therefore must be defined in detail.
  • Both these statements may be called requirements.

4
Wicked Problems Sommerville Vliet
  • Originally this term was defined by Rittel and
    Webber, in 1973.
  • A wicked problem" is a complex problem, i.e.
    this problem is very difficult to define and/or
    identify (e.g. define related entities,
    definitive problems specification).
  • In general, no one can accurately predict
    where/when we can expect the problem and what
    effect it will have on the software production,
    etc.
  • The problem can be tackled after it has happened.

5
Wicked Problems
  • Most large software systems address wicked
    problems.
  • Problems which are so complex that they can never
    be fully understood and where understanding
    develops during the system development.
  • Therefore, requirements are normally both
    incomplete and inconsistent.

6
A Stakeholder ..!!!
  • The notion of stakeholder is used to refer to
    anyone who should have some influence on the
    system requirements, e.g. end-users, engineers,
    business managers, domain experts, etc.

7
Some Reasons for Inconsistency
  • Different stakeholders have different
    requirements and they may define these in
    different ways.
  • There is a constantly shifting compromise in the
    requirements...
  • Different people may negotiate different parts.

8
Some Reasons for Incompleteness
  • Requirements can be interpreted differently.
  • Many requirements can be identified clearly only
    after some experience with the system.
  • Too many details would need to be specified.
  • Customer asks for too little.
  • The world changes.
  • It is difficult to define the level of precision
    in the requirements statements.
  • Informal language (e.g. natural language) does
    not help in requirements statements.

9
Requirements Functional and Non-Functional
  • Functional requirements describe system services
    or functions.
  • Non-functional requirements is a constraint on
    the system or on the development process, e.g.
    timing constraints, standards, etc.

10
Non-Functional Requirements
Non-Functional Requirements
Process Requirements standards, delivery,etc.
External Requirements ethical, legislative
Efficiency Requirements efficiency, reliability,
portability,usability
11
Requirements Engineering
  • The process of establishing the services that
  •  
  • the customer requires from a system …
  • under the constraints with which it operates ...
  • and is developed!

12
The Requirements Engineering Process
Feasibility Study
Requirements Validation
Requirements Definition
1
5
3
2
4
Requirements Analysis
Requirements Specification
13
1. Feasibility study
1
  • Find out if the current user needs can be
    satisfied given the available technology and
    budget?
  • A definition of the problems.
  • Alternative solutions and their expected
    benefits.
  • Required resources, costs, time and delivery
    dates for each alternative solution.

14
2. Requirements Analysis
2
  • Find out what system stakeholders require from
    the system.

15
3. Requirements Definition 4. Requirements
Specification
  • ….
  • The ultimate purpose of the requirements-related
    activities is
  • To understand the goals of the system
  • To document the requirements to be met
  • To specify the qualities required of the software
    solution functionality, performance,
    reliability, etc.

16
3. Requirements Definition
3
  • A statement in natural language plus diagrams of
    the services the system provides and its
    operational constraints.
  • Define the requirements in a form understandable
    to the customer.
  • It represent an understanding between the
    customer and developer of what the customer
    needs/wants.
  • It is usually written jointly by the customer and
    developer.
  • Written for customers.

17
4. Requirements Specification
4
  • A structured document setting out detailed
    descriptions of the system services.
  • Define the requirements in detail.
  • It uses technical terms to define the system
    services a very precise, even mathematical
    description but it must be understandable by
    the client.
  • Written as a contract between client and
    contractor.

18
Software Specification
  • A detailed software description which can serve
    as a basis for a design or implementation.
  • Written for developers.

19
An Example of Requirements Document Structure
(1)
  • Introduction
  • Describe need for the system and how it fits with
    business objectives.
  • Glossary
  • Define technical terms used.
  • System models
  • Define models showing (high level architectural)
    system components and relationships.

20
Requirements Document Structure (cont 2)
  • Non-functional requirements definition
  • Define constraints on the system and the
    development process.
  • System evolution
  • Define fundamental assumptions on which the
    system is based and anticipated changes.
  • Requirements specification
  • Detailed specification of functional requirements.

21
Requirements Document Structure (cont 3)
  • Appendices
  • System hardware platform description.
  • Database requirements (as an ER model perhaps).
  • Index
  • More examples of requirements document can be
    found in Pfleeger, 1998 Sommerville

22
5. Requirements Validation
5
  • Concerned with demonstrating the requirements
    define the system that the customer really wants.
  •  
  • Requirements error costs are high so validation
    is very important ...
  •  
  • Fixing a requirements error after delivery may
    cost up to 100 times the cost of fixing an
    implementation error.
  •  
  • Prototyping is an important technique of
    requirements validation.

23
Requirements Checking
  • Validity Does the system provide the functions
    which best support the customers needs?
  • Consistency Are there any requirements
    conflicts?
  • Completeness Are all functions required by the
    customer included?
  • Realism Can the requirements be implemented
    given available budget and technology?

24
Key Points
  • It is very difficult to formulate a complete and
    consistent requirements specification.
  • A requirements definition, a requirements
    specification and a software specification are
    ways of specifying software for different types
    of reader.
  • The requirements document is a description for
    customers and developers.
  • Requirements errors are usually very expensive to
    correct after system delivery.
  • Reviews involving client and contractor staff are
    used to validate the system requirements.
  • Stable requirements are related to core
    activities of the customer for the software. 
  • Volatile requirements are dependent on the
    context of use for the system.

25
Week 8 24.04.2003-28.04.2003 Project Control
Session
  • Tutorial Time 10 minutes for each Team
  • Students will present project file, particularly
    Schedule, plus any project documentation.
  • Students will describe where they are in the
    project and any problems encountered.
  • During the discussion reviewers will ask to see
    evidence of deliverables for any tasks that are
    complete to determine whether they have in fact
    been done.
About PowerShow.com