presented by murray elowitz jj e research corp 505 453 6358 april 11 2006 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Presented by Murray Elowitz JJ & E Research Corp (505) 453-6358 April 11, 2006 PowerPoint Presentation
Download Presentation
Presented by Murray Elowitz JJ & E Research Corp (505) 453-6358 April 11, 2006

Loading in 2 Seconds...

play fullscreen
1 / 25

Presented by Murray Elowitz JJ & E Research Corp (505) 453-6358 April 11, 2006 - PowerPoint PPT Presentation

  • Uploaded on

REQUIREMENTS FOR PROJECT SUCCESS A Paper by Ralph Young in Crosstalk December, 2006 Presented by Murray Elowitz JJ & E Research Corp (505) 453-6358 April 11, 2006. Background. This paper was published in Crosstalk

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

PowerPoint Slideshow about 'Presented by Murray Elowitz JJ & E Research Corp (505) 453-6358 April 11, 2006' - penha

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
presented by murray elowitz jj e research corp 505 453 6358 april 11 2006

REQUIREMENTS FOR PROJECT SUCCESSA Paper by Ralph Youngin Crosstalk December, 2006

Presented by

Murray Elowitz

JJ & E Research Corp

(505) 453-6358

April 11, 2006

  • This paper was published in Crosstalk
    • Dept of Defense publication
    • By Air Force Software Support Center
  • Young’s paper is a valuable presentation of requirements methodology
  • Applicable to SYSTEMS as well as software
  • Presentation is with permission of the author

Young’s Material

My Comments

key points
Key Points
  • For success, you MUST work on continuous improvement
  • Industry practice hasn’t improved much
    • Failure to work on improving is root cause
  • Need to be AGILE is important

Successful Requirements Process


Improve Project Success and Control Costs

twelve requirements basics for project success
Twelve Requirements Basics for Project Success
  • Include a trained and experienced manager
  • “Partner” with customer.
  • Invest in requirements process.
  • Project vision and scope document.
  • Use proven requirements techniques.
  • Evolutionary or incremental approach .
  • Effective changes control
  • Automated requirements tool
  • Ascertain the rationale for every requirement
  • Inspections of documents.
  • All project staff perform “requirements work”.
  • Proactively address requirements-related risks.
requirements secrets 1
Requirements Secrets (1)
  • Half of the features provided in most delivered software are never used once.
  • More than half of the effort on most systems and software projects is wasted.
  • The “stated requirements” (i.e., the list of requirements provided to the developer by the customer and users) are never the “real requirements”.
  • 80% of requirements errors found in system testing are a result of incorrect “facts” about the requirements or omitted requirements.
  • Spending a lot of effort on testing may be misguided; better to invest more in an effective requirements process that results in higher quality products being provided to test.
requirements secrets 2
Requirements Secrets (2)
  • Given that (a) systems and software development is complex, and b) people (with all of our frailties) are involved, the probability of the development effort becoming derailed is very high—unless a proactive effort is made to “partner for success”.
  • The documents we produce are fraught with errors; the earlier in the development effort those errors (defects) are discovered, the less costly it is to fix them. A peer review process should be implemented to reduce errors. All requirements-related documents should be inspected.
  • Project managers should pay added attention to the requirements basics and allot sufficient funding for requirements-related activities.
requirements secrets 3
Requirements Secrets (3)
  • It’s neither difficult nor expensive to incorporate inspections in your project’s approach; although this technique has been available for a long time, most projects don’t use it.
  • A “defect prevention process” is also very easy to train, deploy, and implement, based on experience on 25 projects. It can save a lot of money and time; again, most projects don’t use it.
  • Communication on most projects is challenged; a proactive effort to foster good communications is required
  • An effective automated requirements tool is required to support requirements development and requirements management on all but tiny projects.

Twelve Requirements –Trained & experienced manager

  • Make sure the project staff includes a trained and experienced requirements manager or requirements analyst.
  • Provide training for all project participants
  • Need a skilled requirements engineer
  • Require a requirements analyst
    • See skills matrix
  • Document the requirements process

This may be a role for a consultant

twelve requirements partnering
Twelve Requirements –Partnering

2. Proactively “partner” with your customer

  • Advantage is evolution of a team committed to project success
    • This can help keep projects funded
twelve requirements invest
Twelve Requirements –Invest

3. Invest in the project’s requirements process.

  • Understand your resource requirements

NASA data: Spend more for successful project

*Lower cost and improved schedule

twelve requirements vision and scope
Twelve Requirements –Vision And Scope

4. Write a project vision and scope document

  • For stakeholders and to obtain buy-in
    • Upward to customers and users
    • Downward to project contributors
  • Everyone helps solve problems
twelve requirements real requirements
Twelve Requirements –Real Requirements
  • Use proven requirements elicitation techniques
  • Need to identify real requirements
  • Vs. stated requirements
    • Especially at project start-up
  • Recommendation: use 2 techniques
    • Workshops
    • Prototypes
  • Involve all key members of team
additional value
Additional Value
  • Rushing to start design is a major start-up problem
    • Ready-Fire-Aim syndrome
    • Design decisions made too early
  • Reflects need to staff rapidly, meet early milestones, provide jobs
    • Designers think they know what THEY have to do

Involving all key members in

Requirements Process alleviates issue

twelve requirements evolutionary approach
Twelve Requirements –Evolutionary Approach

6. Utilize an evolutionary or incremental project approach to development, deployment, and implementation of the capabilities

  • Look for and use new approaches
  • Have someone with experience on staff or USE A CONSULTANT!!!
    • Pay attention to lessons learned
twelve requirements requirements changes
Twelve Requirements –Requirements Changes

7. Use an effective mechanism to control changes to requirements and new requirements.

  • Use high-level CCB for requirements
  • Prioritize requirements
    • Some requirements are “unknowable”
  • Recommendation: < 0.5% changes per month
twelve requirements automated tool
Twelve Requirements –Automated Tool

8. Use an effective automated requirements tool to maintain information about the requirements.

  • Required!
  • Entries must be good requirements
    • See next chart
  • 11 suggested attributes of data
  • Serve needs of different people
the criteria of a good requirement 1
The Criteria of a Good Requirement (1)

•Necessary -- If system can meet real needs without it, it isn’t .

•Feasible -- The requirement is “doable” within available cost and schedule.

•Correct -- The facts related to the requirement are accurate ,,,.

•Concise -- The requirement is stated simply.

•Unambiguous -- The requirement can only be interpreted one way.

•Complete -- Requirement expresses all conditions and whole idea or statement.

•Consistent -- The requirement is not in conflict with other requirements.

•Verifiable -- Can be proved.

the criteria of a good requirement 2
The Criteria of a Good Requirement (2)

•Traceable -- The requirement can be traced to its source and it can be tracked throughout the system (e.g., to the design, code, test, and documentation).

•Allocated --The requirement is assigned to a component of the designed system.

•Design independent -- The requirement does not pose a specific implementation solution.

•Nonredundant -- The requirement is not a duplicate requirement.

•Stated using a standard construct -- The requirement is stated as an imperative using the word shall.

•Associated with a unique identifier -- Each requirement has a unique identifying number.

•Devoid of escape clauses -- Requirements do not use “if”, “when”, “but”, “except”, “unless”, and “although” and do not include speculative or general terms such as “usually”, “generally”, “often”, “normally”, and “typically”.

twelve requirements accurate complete
Twelve Requirements –Accurate & Complete

9. Ensure the facts concerning the requirements are accurate and that important requirements are not omitted. Ascertain the rationale for every requirement (why it is needed).

  • Stakeholder & source docs reviews
  • Completeness by using variety of stakeholders, formal reviews
twelve requirements i nspections
Twelve Requirements – Inspections

10. Conduct inspections of all requirements-related documents. (“Inspections” are a more rigorous form of peer reviews).

  • Utilize inspections
    • Not widely used
twelve requirements enlist support
Twelve Requirements –Enlist support

11. Enlist the support and assistance of all members of the project staff in helping to perform “requirements work”.

  • Use all members of project staff
  • Develops strong sense of teamwork
    • Empowerment

Helps hold back rush to design

twelve requirements address risks
Twelve Requirements –Address Risks

12. Proactively address requirements-related risks.

  • Address risks with discipline
    • Most projects don’t
  • Paper is based on Young’s experience
  • No good excuse for high amount of:
    • Rework
    • Project failures
    • Missing schedules, budgets

Use the requirements basics

in this article