slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering Northrop Grumman Information Technol PowerPoint Presentation
Download Presentation
Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering Northrop Grumman Information Technol

Loading in 2 Seconds...

play fullscreen
1 / 8

Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering Northrop Grumman Information Technol - PowerPoint PPT Presentation


  • 175 Views
  • Uploaded on

How to Implement a Practical Requirements Engineering Approach. Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering Northrop Grumman Information Technology young_ralph@prc.com (703) 556-1030. What is a Practical Requirements Engineering Approach?.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering Northrop Grumman Information Technol' - tauret


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

How to Implement a Practical Requirements Engineering Approach

Dr. Ralph R. Young

Director of Software Engineering

Systems and Process Engineering

Northrop Grumman Information Technology

young_ralph@prc.com

(703) 556-1030

slide2

What is a Practical Requirements Engineering Approach?

Systems Engineering and Program Management WorkshopHow to Implement a Practical Requirements Engineering Approach
  • An organization should develop a requirements process and tailor it for use on each project.
  • The requirements engineering process is a full system life cycle process.
  • A lot of the issues and problems are created in the requirements gathering activities.
    • We can save a lot of time by addressing this area more effectively. Industry data supports this view (see next slide).
    • Further, doing a better job in requirements elicitation reduces rework downstream. Rework = 45% of total project effort, industry wide.
    • The requirements are often unknowable at the inception of many systems and projects. We need to recognize this and deal with it.
  • A requirements tool should be used on every project.
  • Tools don’t obviate the need for trained people, a requirements process, effective practices, and formal requirements training.
  • Customer involvement throughout the project is essential.
  • An incremental development approach works best when the requirements are evolving and changing.
slide4

Acceptance,

integration &

verification

Informing the

enterprise

Provisional

& final

Detailed

Storing and using

acceptance

design &

knowledge from

component

previous projects

development

User

requirements

Developer and Customer Tasks

Developer

work

Architectural

Amount of effort

design

System

requirements

Customer work

Defining

Defining what

Optimizing

Deciding

Linking

Qualifying

Verifying

results

the system

the cost-

on potential

deliverables

the

& validating

for users

must do

benefits

changes

to requirements

design

the product

effective requirements practices

Systems Engineering and Program Management WorkshopHow to Implement a Practical Requirements Engineering Approach

Effective Requirements Practices:
  • Obtain commitment.
    • Consider “Partnering Workshops.”
    • Have and use a “Requirements Policy.”
  • Define the real customer needs and the real requirements.
    • Industry experience shows that the “stated requirements” are never adequate.
    • Consider utilizing a “Joint Team” to be responsible for the requirements.
  • Use and continually improve a requirements process.
  • Iterate the system requirements and architecture repeatedly.
  • Control changes to requirements and new requirements.
  • Select familiar methods.
  • Maintain effective project communication.
  • Maintain a set of work products that together describe the requirements.
  • Perform requirements verification and validation.
  • Use proven development practices.
slide6

Systems Engineering and Program Management WorkshopHow to Implement a Practical Requirements Engineering Approach

Effective Requirements Gathering Practices:

  • Interviews
  • Document Analysis
  • Brainstorming
  • Requirements Workshops, including JAD Workshops
  • Prototyping
  • Use Cases
  • Storyboards
  • Interfaces Analysis
  • Modeling
  • Performance and Capacity Analysis
  • Information Assurance
slide7

Systems Engineering and Program Management WorkshopHow to Implement a Practical Requirements Engineering Approach

The Set of Work Products that might

be considered the “Requirements Specification:”

  • The database in your automated requirements tool
    • Provides “attributes” for each requirement
  • The “Vision and Scope Document” for the project
  • The Requirements Document and other lists or descriptions of requirements provided by the customers and users
  • Lists of requirements met by related legacy (historical) systems
  • The list of system-level (real) requirements evolved by the requirements manager/requirements analysts/engineers
slide8

Systems Engineering and Program Management WorkshopHow to Implement a Practical Requirements Engineering Approach

Some Guidelines to Consider:

  • Meet minimum requirements. Anything more is too much.
  • Prioritize requirements. All requirements are not equal. Address top priority requirements in the initial release.
  • Train requirements analysts/engineers:
    • Not to make requirements decisions.
    • Not to “gold plate.”
    • How to avoid common requirements problems (incorrect facts [49%], omitted requirements [29%], inconsistencies [13%], ambiguities [5%]).
  • Conduct peer reviews of all work products.
  • Document the rationale for each requirement (why it is needed)—this step alone can eliminate up to half of the stated requirements!
  • A one-third change in the requirements equates to a doubling of the cost of the system.
    • Consider having versions/subsequent releases
    • Make concomitant changes in the budget and schedule
  • An agreed-upon understanding of the system is critical to a successful project.