Requirement Management 2
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Requirement Management 2

on

  • 1,645 views

 

Statistics

Views

Total Views
1,645
Views on SlideShare
1,638
Embed Views
7

Actions

Likes
0
Downloads
97
Comments
0

1 Embed 7

http://www.slideshare.net 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Requirement Management 2 Presentation Transcript

  • 1. What Are Requirements?
    • Definition:
    • Requirements are the things that you should discover before starting to build your product
  • 2. Requirements Specification Requirements Process Product Usage Build Product Design Systems Analysis Analysis Feedback Design Feedback Build Feedback Product Product Feedback Stakeholder Wants and Needs Intended Operating Environment Analysis Specification and Requirements Specification Design Specification Role of Requirements in the Development Process
  • 3. Requirements Gatherings
    • The requirements gatherers are busy discovering the business goals
    • What the product?
    • What it has to do?
    • What qualities it must have?
    • What constraints it must conform?
    • What interfaces it has to the outside world?
  • 4.  
  • 5. What is a Requirement?
    • A requirement is something that the product must do or a quality that the product must have
    • A requirement exists either because the type of product demands certain functional qualities
    • or
    • The client wants that requirement to be part of the delivered product.
  • 6. Types of Requirements
    • Functional Requirements
      • The requirements that specify the inputs (stimuli) to the system, the outputs (Resources )from the system, and the behavioral relationship between them
    • Non-Functional Requirements
      • Performance
      • Environment
      • Security
      • Testability
      • Understandability / Usability
  • 7. Functional Requirements
    • You are about to build a new product
    • What does it have to do?
    • Control an aircraft?
    • Predict profitability for your organization?
    • Turn satellite data into graphic displays for broadcast?
    • What are the things that it has to do to achieve that purpose?
  • 8. Functional Requirements
    • Functional requirements are things the product must do
    • The product shall produce an amended de-icing schedule when a change to a truck status
    • Means that previously schedule work cannot be carried out as planned
  • 9. Non-Functional Requirements
    • What qualities must the product have?
    • Does it have to be fast?
    • Or easy to use?
    • Secure from hacking
  • 10. Non-functional Requirements
    • Non-functional requirements are
      • properties, that the product must have
      • qualities the product must have.
  • 11. Non-functional Requirement Types
  • 12. Functional vs Non-functional
    • “ What” of the system
    • Function and
    • Data related
    • “ How well” aspects of the system
    • Performance
    • Maintainability
    • Scalability
    • Interoperability
    • Reliability
    • Portability and
    • Constraints
  • 13. Functional Vs Non-Functional Requirements
    • What the product must do
    • They govern the basis set of duties or functions that the product should be doing
    • A system can not work if the functional requirements are not satisfied
    • They satisfy the stated needs of the customers
    • The other special attributes the product must possess
    • They govern the extra set of duties that it should perform
    • These are mainly aimed at maintenance of SW
    • They satisfy the implied needs of the customer
  • 14. Constraints
    • They apply to the entire product and are preferably defined before beginning work on gathering the requirements
    • Constraints are global issues that shape the requirements
  • 15. Product Constraints
    • The purpose of the Product – the reason for building the product and the business advantage if we do so
    • The Client, Customer and other Stakeholders – the people with an interest in the product
    • Users of the Product – the intended end-users, and how they affect the product’s usability
  • 16. Product Constraints Contd..
    • Requirements Constraints – limitations on the project, and restrictions on the design of the product
    • Naming Conventions and Definitions – the vocabulary of the product
    • Relevant Facts – outside influences that make some difference to this product
    • Assumptions – that the developers are making
  • 17. Functional Requirements
    • The scope of the product – defines the product boundaries, and its connections to adjacent systems
    • Functional and Data Requirements – things the product must do and the data manipulated by the functions
  • 18. Non-functional Requirements
    • Look and Feel Requirements – the product’s qualities
    • Usability Requirements – based on the intended users
    • Performance Requirements – how fast, big, accurate, safe, reliable etc.
    • Operational Requirements – the product’s intended operating environment
  • 19. Non-functional Requirements Contd.
    • Maintainability and Portability Requirements – how changeable the product must be
    • Security Requirements – the security, confidentiality and integrity of the product
    • Cultural and Political Requirements – human factors
    • Legal Requirements – conformance to applicable laws
  • 20. Importance of non-functional Requirements
    • Often persons gathering requirements focus on functional requirements
    • Non functional requirements are missed out
    • Users may never accept system that meet all the functional requirements but ignore some important non-functional requirements
  • 21. Project Issues
    • Open Issues – as yet unresolved issues with a possible bearing on the success of the product
    • Off-the-Shelf Solutions – ready-made components that might be used instead of building something
    • New Problems – caused by the introduction of the new product
    • Tasks – things to be done to bring the product into production
  • 22. Project Issues Contd..
    • Cutover – tasks to convert from existing systems
    • Risks – the risks that the project is most likely to face
    • Cost- early estimates of the cost or effort needed to build the product
    • User Documentation – the plan for building the user instructions and documentation
    • Waiting Room – requirements that might be included in future releases of the product
  • 23. Requirement #: Unique Id Requirement Type: Template section Event/use case #: Origin of the requirement
    • Description: A one-sentence statement of the intention of the requirement
    • Rationale : Why is this requirement considered important or necessary?
    • Source : Who raised this requirement?
    • Fit Criteria: A quantification of the requirement used to determine whether the solution meets the requirement
    • Customer Satisfaction: Measures the desire to have the requirement implemented
  • 24.
    • Customer Dissatisfaction : Unhappiness if it is not implemented
    • Dependencies : Other requirements with a change effect
    • Conflicts : Requirements that contradict this one
    • Supporting Materials : Pointer to supporting information
    • History : Origin and changes to the requirement
  • 25. Skill Set
    • Requirement engineer should possess the following:
    • Interviewing skills
    • Group work skills
    • Facilitation skills
    • Negotiation skills
    • Analytical skills
    • Problem solving skills
    • Presentation skills
  • 26. Skill Set contd…
    • Modeling skills
    • Practical knowledge of CASE tools
    • Knowledge and experience in
      • Using modeling techniques and languages
      • Management and traceability tools
    • Product planning and marketing knowledge
  • 27. Reference
    • Never Go to a client meeting without a prototype
    • Michael Schrage
    • IEEE Software, April 2004, pages 42-45