Requirement Management 1


Published on

learn RM from baunoec

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Requirement Management 1

  1. 1. Systems Requirements Engineering Prof M L Saikumar Institute of Public Enterprise
  2. 2. Requirements <ul><li>Requirement Analysis - Tajmahal </li></ul><ul><li>Walking on water and Developing software from specifications are easy </li></ul><ul><li>If both are frozen </li></ul><ul><li>Requirements without activity – Activity without Requirements </li></ul><ul><li>Software Demo </li></ul><ul><li>Fully Automated Aircraft </li></ul>
  3. 3. Why are Requirements so Important?
  4. 4. Software Development Cycle <ul><li>Waterfall model </li></ul><ul><li>Prototyping </li></ul><ul><li>Spiral model </li></ul>
  5. 5. Definition <ul><li>Requirements are…. A specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system. </li></ul>
  6. 6. The Rationale for Focus on Requirements (Industry Data: 8,000 software projects) <ul><li>53% of industry’s investment on application development projects is a casualty of cost overruns and failed projects </li></ul><ul><li>Major contributing factors include: lack of user input (13%); incomplete requirements (12%); and changing requirements. </li></ul><ul><li>Reducing requirements errors is the single most effective action developers can take to improve project outcomes. </li></ul>
  7. 7. <ul><li>There is as much as a 2000:1 cost savings from finding errors in the requirements stage vs. in the maintenance stage of the life-cycle. </li></ul><ul><li>Requirements errors are the largest class of errors typically found in a project (41-56% of errors are discovered). </li></ul><ul><li>The cost of rework is typically 45% of projects. </li></ul>
  8. 8. Typical Customer and Supplier Issues and Remedies Customer Supplier Remedies 1. Use domain experts 2. Consider technology change management Lacks subject matter expertise to address functional needs 5. Doesn’t update the statement of current user operating concepts or technology improvements 1. Emerge the high level real requirements 2. Strengthen commitment/gain a “shared vision” Doesn’t engage the client in a process to distill the real needs 4. Provides overly specific specifications 1. Take proactive steps to improve communications 2. Utilize a peer review process Doesn’t encourage and nurture more effective communication 3. Doesn’t communicate the need effectively 1. Utilize a joint team 2. Meet minimum requirements Is unwilling/unable to meet true needs within fiscal boundaries 2. Doesn’t understand what is achievable within fiscal boundaries 1. Invest more in the requirements process 2. Define the real customer needs Doesn’t understand the customer’s need 1. Doesn’t understand the real need
  9. 9. Difficulties in Requirements Analysis <ul><li>For the client, </li></ul><ul><ul><li>requirements are an end in, and of themselves </li></ul></ul><ul><li>For the IT professional, </li></ul><ul><ul><li>requirements are a means to an end </li></ul></ul><ul><li>This is market mismatch </li></ul>
  10. 10. Difficulties in Requirements Analysis <ul><li>Insufficient time allowed </li></ul><ul><li>Insufficient or inefficient review with users </li></ul><ul><li>Differences of opinion </li></ul><ul><li>Political twists and turns </li></ul><ul><li>Lack of technical knowledge </li></ul><ul><li>Inability to write well </li></ul><ul><li>Lack of structured analysis techniques </li></ul>
  11. 11. Risks from Inadequate Requirements Processes <ul><li>Insufficient user involvement leads to unacceptable products </li></ul><ul><li>Creeping user requirements contribute to overruns and degrade product quality </li></ul><ul><li>Ambiguous requirements lead to ill-spent time and rework </li></ul><ul><li>Gold-plating by developers and users adds unnecessary features </li></ul>
  12. 12. <ul><li>Minimal specifications lead to missing key requirements </li></ul><ul><li>Overlooking the needs of certain user classes leads to dissatisfied customers </li></ul><ul><li>Incompletely defined requirements make accurate project planning and tracking impossible </li></ul>
  13. 13. Requirement Statement Characteristics <ul><li>Complete </li></ul><ul><li>Correct </li></ul><ul><li>Feasible </li></ul><ul><li>Necessary </li></ul><ul><li>Prioritized </li></ul><ul><li>Unambiguous </li></ul><ul><li>Verifiable </li></ul>
  14. 14. Requirement Specification Characteristics <ul><li>Complete </li></ul><ul><li>Consistent </li></ul><ul><li>Modifiable </li></ul><ul><li>Traceable </li></ul>
  15. 15. Hierarchical Decomposition of the Requirements Engineering Domain Requirements Engineering Requirements Development Requirements Management Elicitation Analysis Specification Verification
  16. 16. Requirements Development Activities <ul><li>Identifying the expected user classes for the product </li></ul><ul><li>Eliciting needs from individuals who represent each user class </li></ul><ul><li>Understanding actual user tasks and objectives </li></ul><ul><li>Analyzing the information received from users </li></ul><ul><li>Partitioning system-level requirements into major subsystems . </li></ul>
  17. 17. <ul><li>Understanding the relative importance of quality attributes </li></ul><ul><li>Negotiating implementation priorities </li></ul><ul><li>Translating the collected user needs into written specifications and models </li></ul><ul><li>Reviewing the requirements specifications Understanding the relative importance of quality attributes </li></ul><ul><li>Negotiating implementation priorities </li></ul><ul><li>Translating the collected user needs into written specifications and models </li></ul><ul><li>Reviewing the requirements specifications </li></ul>
  18. 19. Requirements Management Activities <ul><li>Defining the requirements baseline </li></ul><ul><li>Reviewing proposed requirements </li></ul><ul><li>Incorporating approved requirements changes into the project in a controlled way </li></ul><ul><li>Keeping projects plans current with the requirements </li></ul><ul><li>Negotiating new commitments based on the estimated impact of changed requirements </li></ul><ul><li>Tracing individual requirements to their corresponding designs, source code, and test cases </li></ul><ul><li>Tracking requirements status and change activity throughout the project. </li></ul>
  19. 20. Req Mgmnt Vs Req Engg <ul><li>It includes all activities that maintain the integrity and accuracy </li></ul><ul><li>It includes controlling changes to the requirements baseline </li></ul><ul><li>It deals with the application of the requirements in developing the system </li></ul><ul><li>It deals with maintaining tractability of requirements </li></ul><ul><li>It is the systematic use of principles, techniques and tools </li></ul><ul><li>It deals with the evolution of requirements </li></ul><ul><li>It checks the feasibility in terms of cost, time and resources </li></ul><ul><li>It comes before the Req management </li></ul>
  20. 21. SW Req Engg Vs Systems Req Engg <ul><li>This is a subset of Systems RE </li></ul><ul><li>It involves how the requirements to be met </li></ul><ul><li>It is one of the first activity of SW development life cycle </li></ul><ul><li>It ends after producing SRS document </li></ul><ul><li>It includes SW and HW Requirements Engineering </li></ul><ul><li>It involves in knowing what is to be accomplished by the system </li></ul><ul><li>It is usually performed iteratively, alternating with system design </li></ul>
  21. 22. SW Req Engg Vs Systems Req Engg <ul><li>Technical skills are required while doing SW requirements Engg </li></ul><ul><li>SWRS serves as a product validation check </li></ul><ul><li>It is secondary stage of development cycle </li></ul><ul><li>Focuses on Technical issues </li></ul><ul><li>Technical as well as non-technical skills are required while doing Systems RE </li></ul><ul><li>SRS serves as a customer validation check </li></ul><ul><li>It is primary stage of development cycle </li></ul><ul><li>Focuses on Functional issues </li></ul>
  22. 23. Reference <ul><li>Developing the Requirements discipline Software Vs Systems </li></ul><ul><li>Rezine Gonzales </li></ul><ul><li>IEEE Software, March/April 2005, pages 59-61 </li></ul>
  23. 24. Exercise <ul><li>Write down any requirements-related problems you have encountered on your current or previous classes. Identify each as a requirements development or requirements management problem. Identify the impact caused by each problem and the root cause of each problem. </li></ul><ul><li>Facilitate a discussion with your team members and other stakeholders on requirements – related problems from your current or previous class, their impacts, and their root causes. Explain to the participants that they have to begin confronting these difficult issues if they ever hope to master them. Are they ready to try? </li></ul>
  24. 25. References <ul><li>1. Mastering the Requirements Process </li></ul><ul><li>Robertson & Robertson, Addison Wesley </li></ul><ul><li>2. Software Requirements </li></ul><ul><li>Karl E. Wiegers, Microsoft press </li></ul><ul><li>3. User-Centered Requirements Analysis </li></ul><ul><li>Charles F. Martin, Prentice-hall </li></ul><ul><li>4. Writing Better Requirements </li></ul><ul><li> Alexander & Stevens, Addison wesley, 2002 </li></ul><ul><li>5. An Introduction to Requirements Engineering </li></ul><ul><li> Ian K Bray, Addison wesley, 2002 </li></ul><ul><li>6. Requirements Engineering Process & Techniques </li></ul><ul><li> Kotonya & Sommerville, John wiley, 1998 </li></ul>
  25. 26. References <ul><li>7. Practical Software Requirements </li></ul><ul><li> Benjamin& Kovitz, Manning, 1999 </li></ul><ul><li>8. Writing Effective Use Cases </li></ul><ul><li> Alistair Cockburn, Addison Wesley, 2001 </li></ul><ul><li>9. Patterns for Effective Use cases </li></ul><ul><li> Adolph & Bramble, Addison wesley, 2003 </li></ul><ul><li>10 Engineering and Managing Software Rquirements </li></ul><ul><li>Aurum, Wohlin, Springer Verlag, 2005 </li></ul><ul><li>11 Software Requirements Engineering </li></ul><ul><li>Thayer, Dorfman </li></ul><ul><li>12 Requirements by Collaboration </li></ul><ul><li>Gottesdiener, Addison Wesley </li></ul>
  26. 27. Websites <ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> , , </li></ul><ul><li> </li></ul><ul><li> </li></ul>