1 / 45

Requirements IEEE Standard Glossary

Requirements IEEE Standard Glossary. A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or processed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

milton
Télécharger la présentation

Requirements IEEE Standard Glossary

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements IEEE Standard Glossary • A condition or capability needed by a user to solve a problem or achieve an objective. • A condition or capability that must be met or processed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. Computer Engineering 203 R Smith Requirements Management 6/2009

  2. Quote from Frederick Brooks • 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 technical 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. Computer Engineering 203 R Smith Requirements Management 6/2009

  3. Why are Requirements Critical? • In over 8,000 projects conducted by 350 companies, only 16 percent of projects were considered successful, on time and within budget. • Studies continue to show that errors in requirements are the most significant factor in project failure. • Errors in requirements have the greatest impact on project resources, time, personnel, etc. • Costs to correct problems increase over time Computer Engineering 203 R Smith Requirements Management 6/2009

  4. Scope and Requirements • The text uses the term “scope” to cover both the project vision and requirements. • Think about project vision, scope and requirements as layers of detail. • Project vision being the highest level and requirements being the most detailed. • Each layer addresses a different need. Computer Engineering 203 R Smith Requirements Management 6/2009

  5. Scope and Requirements • While each layer provides greater detail each layer must fit within the higher layers. • The Project Vision provides a filter to measure all requirements. • For example all requirements must be traced back to the project scope and the scope must fit within the project vision. Computer Engineering 203 R Smith Requirements Management 6/2009

  6. Vision/Scope Statement • Provides the answers to basic questions • What need will the project satisfy? • Who is the project for? • What is not in the project? • The Vision statement provides a base to trace all requirements too. • The Vision statement help establish project buy-in. Computer Engineering 203 R Smith Requirements Management 6/2009

  7. From Vision to Requirements • The Vision/Scope sets the framework, creating requirements adds detail. • All code that is written for a project should be in response to a requirement. • The Vision justifies all other work Computer Engineering 203 R Smith Requirements Management 6/2009

  8. What Makes Good Requirement? • All stakeholders have the same vision of the requirement. • That it can be built and tested. • The end result of different developers each developing the same requirement will be essentially the same. Computer Engineering 203 R Smith Requirements Management 6/2009

  9. Unambiguous • All readers of a requirement statement should arrive at a single consistent interpretation of it. • How to achieve unambiguous requirements: • Ensure the frame of reference is consistent • Use modeling, UML • Use prototypes Computer Engineering 203 R Smith Requirements Management 6/2009

  10. Necessary • Each requirement should document something the customer needs. • The need can be traced back to the vision. • The Vision can be traced back to the customer. Computer Engineering 203 R Smith Requirements Management 6/2009

  11. Complete • Is each requirement fully described? • Does the developer have all the information needed to begin design? • Will the developer need to refer to the customer for missing details? Computer Engineering 203 R Smith Requirements Management 6/2009

  12. Realistic • Is the requirement beyond the limitations of the systems environment? • Is the requirement beyond the scope of technology? Computer Engineering 203 R Smith Requirements Management 6/2009

  13. Verifiable • Can tests be written to verify that the requirement can be met? • Can you write a test that verifies that a user interface is: • “Good” • “Easy to use” • Can it be determined objectively if a requirement has been met? Computer Engineering 203 R Smith Requirements Management 6/2009

  14. Consistent • Do requirements conflict with other requirements? • Being easy to “learn” and “feature rich” are often in conflict. • Developing something in a set time frame and having a limited budget are often in conflict. Computer Engineering 203 R Smith Requirements Management 6/2009

  15. Traceable • Traceable goes in both directions • External to the customer • Internal to the code • Can you trace the requirement back to the customer? • Can elements, code, test cases and documentation be traced to a requirement? • If code does not implement a requirement then why is it being implemented? Computer Engineering 203 R Smith Requirements Management 6/2009

  16. Why are Good Requirements Important? • Improved Efficiency • Reduces delays for clarification. • Less Rework • Getting it right the first time reduces waste. • Reduced Risk • Less Friction • Giving the customer what they want. Computer Engineering 203 R Smith Requirements Management 6/2009

  17. Scope and Requirements • Does user involvement solve everything? • Is the user fully informed? • Do they have authority? • Is what is in and what is not included clearly described? • Assumptions are made too easily • Is a change control mechanism provided. • Ensure changes happen in planned manner • Communications • Everyone is informed when changes happen Computer Engineering 203 R Smith Requirements Management 6/2009

  18. Role of a Requirements Process • Provides discipline to make requirements gathering predictable. • Communicates to those involved what is expected of them. • Establishes a baseline for future improvement to gathering requirements. Computer Engineering 203 R Smith Requirements Management 6/2009

  19. Why is a requirements process needed? • Ensure quality in establishing the requirements. • Change will always be expensive. Computer Engineering 203 R Smith Requirements Management 6/2009

  20. Steps in the Requirements Process • Requirements Elicitation • How are we going to get the requirements? • From whom do we get requirements? • Requirements Analysis • What do the requirements actually mean? • Requirements Documentation • Making a record of the decisions made. • Requirement Verification • Getting agreement on the work to be done. Computer Engineering 203 R Smith Requirements Management 6/2009

  21. Common Problems with Requirements • Requirements are not Consistent with the Vision. • Requirements are ambiguous and are based on assumptions, which allows multiple interpretations. • Requirements are based on the design and not the Vision. Computer Engineering 203 R Smith Requirements Management 6/2009

  22. Common Problems with Requirements • All sources of requirements are not identified. • All stakeholders are not informed of the requirements. Computer Engineering 203 R Smith Requirements Management 6/2009

  23. Relationship between Planning and Requirements • You need requirements to have a completed plan. • You need a plan too know if your requirements can be successfully implemented. Computer Engineering 203 R Smith Requirements Management 6/2009

  24. Where do Requirements come from? • Customers • Industry standards • Business goals • Company priorities • Government standards Computer Engineering 203 R Smith Requirements Management 6/2009

  25. Types of Requirements • Functional requirements • Nonfunctional and Pseudo requirements • Systems requirements • User requirements • Business requirements • Quality attributes Computer Engineering 203 R Smith Requirements Management 6/2009

  26. Functional Requirements • Behavior of the system • Operations it should perform • Inputs it should accept • Output it should produce Computer Engineering 203 R Smith Requirements Management 6/2009

  27. Nonfunctional and Pseudo Requirements • Industry/Company standards • Windows Look and Feel • Government regulations • How records are kept • Market requirements • Internet/X.400 Computer Engineering 203 R Smith Requirements Management 6/2009

  28. Best Practices in Requirements Elicitation • Have a vision and scope statement • Agree on the project’s objective • Define the requirements procedure • Identify users/stakeholders • Where do we get requirements from • Involve the user • Analyze user workflow • Uncover what assumptions have been made. Computer Engineering 203 R Smith Requirements Management 6/2009

  29. Requirements Analysis • Draw a system context diagram • Create models and prototypes • Create a data dictionary • Analyze feasibility • Prioritize requirements • Risk Management Computer Engineering 203 R Smith Requirements Management 6/2009

  30. Create Models and Prototypes • Use Cases • Data Flow Diagrams • Entity Relationship Diagrams • State Transition Diagrams Computer Engineering 203 R Smith Requirements Management 6/2009

  31. Create a Data Dictionary • The Data Dictionary is the glue that holds requirements and models together. • Primitive data elements • Data structures or records • Iterations within data structures Computer Engineering 203 R Smith Requirements Management 6/2009

  32. Analyze Feasibility • Determine the risks • Unfamiliar tools, technologies, methods, hardware, etc • How complex is it? • How rigid are the requirements? Computer Engineering 203 R Smith Requirements Management 6/2009

  33. Prioritize Requirements • Look at the risks. • Look at the dependencies. • Look at the availability of resources. • Look at customer interest. • What will make the customer happy. • Look at visibility. • Can we show progress? Computer Engineering 203 R Smith Requirements Management 6/2009

  34. Risk Management • How do risks impact the requirements? • What are priorities? • What requirements can be delayed to make time to allow for risks? Computer Engineering 203 R Smith Requirements Management 6/2009

  35. Traceability Matrix • Best practice would establish a traceability matrix for all requirements. • All code, tests and documentation must trace back to a requirement. • Requirements must have associated code, tests and documentation. • The matrix ties everything together. Computer Engineering 203 R Smith Requirements Management 6/2009

  36. Best Practices in Documenting Requirements • Requirements should be inspected • Unambiguous • Measurable • Use writing standards, common syntax when documenting requirements • Define all data • Use pictures and diagrams Computer Engineering 203 R Smith Requirements Management 6/2009

  37. Requirements Verification • Inspect requirements documents • Look for common errors • Write test cases from requirements • Write user manual from requirements • Is sign-off enough? • If there is not informed buy-in then there is always room for disagreement. Computer Engineering 203 R Smith Requirements Management 6/2009

  38. Inspect Requirements Documents • Doing formal inspections of requirements eliminates requirements problems early in the development process • Builds a common understanding of the requirements Computer Engineering 203 R Smith Requirements Management 6/2009

  39. Is Sign-off Enough? • Is sign-off enough if you know the work is sub-par? • Avoided problems will come back to haunt you. • Was the sign-off done after careful review or was it done because it was expected in the schedule? Computer Engineering 203 R Smith Requirements Management 6/2009

  40. Requirements Management • From Requirements to Project Plans • Change Control • Version Control • Requirements Tracing • Requirements Status Tracking Computer Engineering 203 R Smith Requirements Management 6/2009

  41. From Requirements to Project Plans • Creating the roadmap • Priorities • Estimates • Risks • Dependencies Computer Engineering 203 R Smith Requirements Management 6/2009

  42. Change Control • Change Control Boards • Use of contingency in estimating the size of the work Computer Engineering 203 R Smith Requirements Management 6/2009

  43. Version Control • Tracking when requirements were added or dropped • Tracking who and why a change was requested • Tracking the impact of the change • Tracking who approved the change Computer Engineering 203 R Smith Requirements Management 6/2009

  44. Requirements Tracing • What is needed to justify the work involved in tracing requirements? • Customer satisfaction • Not doing more work then required • Ensuring that all parts of the project come together • Documentation • Support • Test Computer Engineering 203 R Smith Requirements Management 6/2009

  45. Requirements Status Tracking • As part of normal schedule tracking, follow the progress of development. • Allow for partial releases of functionality within status tracking. Computer Engineering 203 R Smith Requirements Management 6/2009

More Related