Lecture 4: Requirements Engineering - PowerPoint PPT Presentation

Loading...

PPT – Lecture 4: Requirements Engineering PowerPoint presentation | free to view - id: 74a655-NTg5M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Lecture 4: Requirements Engineering

Description:

Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering – PowerPoint PPT presentation

Number of Views:53
Avg rating:3.0/5.0
Slides: 26
Provided by: Seth87
Category:

less

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

Title: Lecture 4: Requirements Engineering


1
Lecture 4 Requirements Engineering
  • COSI 120b, Principles of Software Engineering

2
All Software Starts With Requirements
  • What should this application do?
  • How should it react?
  • What should it accomplish?
  • Who should it be targeted to?
  • What are the priorities?
  • What defines success?

3
Good Software Starts With Good Requirements
  • Underspecified requirements can result in a
    poorly defined application
  • If the priorities are unclear, the application
    may appear incomplete to the customer
  • If interactions are ambiguous, the application
    may not respond correctly
  • If the application functionality is
    underspecified, features may not be implemented
    correctly
  • If success is undefined, how do you know what you
    are trying to do?

4
Bad Software Starts With Bad Requirements
  • 40 - 60 percent of all defects can be traced to
    bad requirements (Davis, 1993, Leffingwell, 1997)
  • Defects in the requirements stage may be the most
    expensive to fix later on (Brooks, 1995)
  • Two most frequently reported problems in industry
    are specifying and managing requirements (ESPITI,
    1995)

5
No Silver Bullet
  • The hardest single part of building a software
    system is deciding precisely what to build. No
    other part of the conceptual work is as difficult
    as establishing the detailed technique
    requirements, including all the interfaces to
    people, to machines, and to other software
    systems. No other part of the work so cripples
    the resulting system if done wrong. No other
    part is more difficult to rectify later
  • - No Silver Bullet Essence and Accidents of
    Software Engineering (Brooks, 1987)

6
Cost of Change
7
Overview
  • Stakeholders
  • What is a requirement?
  • Parts of a requirement
  • Requirements Process
  • Establishing Scope
  • Functional Requirements
  • Prototyping and XP
  • Conclusions

8
Stakeholders
  • Requirements come from somewhere
  • If they only came from one source, that would be
    easy
  • Requirements may come from multiple sources, and
    may be altered by still more
  • These people are stakeholders

9
Stakeholders
  • Customers who fund the project
  • Direct funding, acquisition funding, etc
  • Users who interact with the product
  • UI designers
  • Requirements analyst
  • Someone in your organization that interfaces with
    the customer
  • Fellow Developers
  • Especially if the application has multiple stages
    of development

10
Stakeholders
  • Testers
  • Determine correctness
  • Documentation writers
  • Project Managers
  • Legal Staff
  • Intellectual property
  • Legal guidance
  • Manufacturing
  • Sales, marketing, field support, help desk

11
Stakeholders
  • Dealing with the stakeholders
  • Is a given stakeholder authorized to give you a
    new requirement?
  • A sales person who promises a new feature
  • How does the requirement interface with existing
    requirements?
  • Does it conflict with existing requirements?
  • How does the requirement effect the success
    metric?
  • If it increases the work, what happens to your
    promised delivery date?
  • Is it possible?
  • perpetual energy

12
What is a requirement?
  • A capability or condition needed by a user to
    solve a problem or achieve an objective
  • A condition or capability that must be met or
    possessed by a system or system component to
    satisfy a contract, standard, specification, or
    other formally imposed document

13
What are requirements?
  • What is the problem?
  • Projects scope may not defined
  • Customers are too busy with the design
  • Project managers or sales people give conflicting
    requirements
  • Authoritative requirements exist in the head of
    the project manager alone
  • Lack of prioritization
  • Ambiguous requirements

14
What are requirements
  • More problems
  • Focus on UI, not the functionality
  • Requirements are signed-off, yet continue to
    change
  • Project scope increases, yet resources do not
  • Lost requirements
  • Unknown status
  • Unused functionality
  • Completed to specification, but the customer is
    still not happy

15
What are requirements
  • How do we avoid these problems?
  • Well specified requirements
  • Techniques to manage requirements
  • Understanding of how requirements can hurt and
    help the project
  • Techniques to elicit reasonable requirements out
    of stakeholders
  • Techniques to reconcile requirements

16
Types of Requirements
17
Requirements Process
  • Elicitation
  • Defining the stakeholders
  • Getting the needs for stakeholder representatives
  • Analysis
  • Taking the elicited requirements and turning them
    into useful objects
  • Tasks
  • Business rules
  • Functional requirements
  • Nonfunctional requirements

18
Requirements Process
  • Specification
  • Requirements to system components and system
    architecture
  • Negotiation of implementation priorities
  • Translation into written requirements,
    specifications and models
  • Validation
  • Reviewing the documented requirements with the
    customer
  • Correct any problems before design starts

19
Requirements Management
  • Requirements baseline
  • Evaluating changes before approving
  • Change Control Board
  • Incorporating approved changes in a controlled
    fashion
  • Keeping deadlines and timelines in sync
  • Negotiating new commitments
  • Incorporating new requirements into the baseline

20
Requirements Management
21
Good Requirements
  • The characteristics of good requirement
    statements
  • Complete
  • Correct
  • Feasible
  • Necessary
  • Prioritized
  • Unambiguous
  • Verifiable

22
Good Requirements
  • The characteristics of good requirement
    specifications
  • Complete
  • Consistent
  • Modifiable
  • Traceable

23
Conclusions
  • Requirements are important
  • Cost of change
  • Next class we will talk about
  • Gathering requirements
  • Formalizing requirements
  • Requirements are hard to get right
  • As you are about to find out

24
Assignment 1a
  • Think about building a new Word Processor
  • Everyone will be assigned a stakeholder
  • For the class one week from today, come up with a
    set of requirements that you, in the role of a
    stakeholder, would request
  • Be prepared to present these requirements
  • Work ALONE
  • Send me (seth_at_cs.brandeis.edu) your requirements
    by 5pm on Sunday (2/6/2005)

25
Stakeholder Roles for Assignment 1a
  • Customer
  • UI Designer
  • Tester
  • Sales
  • End User
About PowerShow.com