Requirements Development

1. Requirements Development VIASYS Healthcare

2. What is a requirement? • A condition or a capability needed by a user to solve a problem or achieve an objective. • A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed document. • A documented representation of a condition or capability as in (1) or (2). • [Source: IEEE definition]

3. Why focus on Requirements? • Meet Schedule/Cost objective • Writing down requirements makes the project more predictable. • Requirement defects lead to the most rework of all defect types. (I’ve seen lots of numbers, all of them over 60%) • Reducing requirements & design defects early can give you 7:1 ROI or better! [Google for “defect dollarization” – Tim Olson of QIC]

4. Example Project Schedule • An example of costs accrued when a requirement changes late in the project or was not understood during design. • Product allows user to scan a bar code and display an item number associated with it.

5. Project Schedule

6. Requirement Change • The project is 70% completed when the marketing group realizes that some of the customers are using a different bar coder. • It is decided that software should be able to use the ScanTronics GT-15 bar code reader to read in bar codes.

7. Project Schedule Updated

8. IMPORTANT SLIDE!!!!!! • Most requirements changes will have a measurable impact on both cost/schedule for the project. • This impact should be weighed against the need for the requirement before the decision to make a change is made.

9. Why focus on Requirements? • Achieve high customer satisfaction • Customers are more likely to receive products they want, at the time you’ve promised it will be ready. • Requirements are a baseline to determine product quality. • Higher quality, lower cost as customer needs are tracked throughout the development process.

10. Requirements elicitation • Interviews/User surveys • Use Case Analysis & Brainstorming • Quality Function Deployment • Enhancement suggestions • Extraction from external documents (FDA regulations etc.. • Competitive Reviews

11. Requirements Management • Inspecting requirements – single most productive practice to increase quality! • Creating a baseline • Planning the project • Tracking changes • Manage project cost & risk

12. Characteristics of a good requirement. • Correct (marketing) • Necessary (marketing) • Attainable (engineering) • Verifiable (engineering, testing) • Traceable (all) • Unambiguous (all) Writing good requirements is a team effort!

13. Nice to have • Implementation Neutral- allows engineers to decide upon implementation: state requirements in terms of customer need, not perceived means • Prioritized- communicates how important of features to the team and allows the team to work on “must have” features first: Requirements almost always exceed the time and budget available

14. Types of Requirements • Functional- things the system does • Performance- how fast the system must do functions • External Interfaces- other systems it must “talk” with • Design Constraints- regulations, hardware needs etc…that restrict implementation • Quality Attributes- security, reliability, maintainability..etc

15. Baseline Requirements • Baseline Requirements- these are the agreed upon requirements when design and development begin. • Requirements always change, the baseline is just the starting point (perfectionists beware!) • Any changes to this Baseline have impact on the schedule and must be carefully analyzed for schedule and cost impact.

16. Writing good requirements • Avoid words like “maximize”, “rapid”, “user friendly”, “easy”, “sufficient” –Remember this must be testable/verifiable. • Avoid using “and” and “or”. Probably stating multiple requirements.

17. Some Requirements Fields • Unique ID - traceable • Category / Type • Title (optional) • Description • Assessment – testable • Exception • Justification

18. More Requirements Fields • Originator – who wrote it • Priority (< “High” means on Candidate list) • Product, product version • References • Issue ID • “Firm” or “Fluid” • Notes (catch-all free text field)

19. Example #1 • The system shall read a bar code and instantaneously display the item number.

20. Example #2 • The system shall display a graphic image of the the bar code to the user after a successful scan.

21. Example #3 • The system should warn the user if the bar code scan failed.

22. Example #4 • Must be an industrial version of our current system.

23. Example #5 • The system shall allow the user to adjust font, color, and size for the displayed item and save these settings each time the program is closed, plus allow the user to pick from a list of settings groups in the program options.

24. Workshop Requirements • Write requirements for a small software program that lets the user look up a name and address from a telephone number. The data is stored in an XML database.

25. References • IEEE Standard Glossary of Software Engineering Terminology, IEEE STD 610.12-1990, http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html • Quality Function Deployment, Ronald G. Day, ASQC Quality Press, 1993. • Christensen, Mark J. and Thayer, Richard H. The Project Manager’s Guide to Software Engineering’s Best Practices, IEEE Computer Society, 2001 • Wiegers, Karl E., Software Requirements, Microsoft Press, 1999 • Wiegers, Karl E., “Writing Quality Requirements”, http://www.processimpact.com/articles/qualreqs.html • Hooks, Ivy, “Writing Good Requirements”, http://www.complianceautomation.com/papers/writingreqs.htm, INCOSE 1993

26. Author Kevin Menningen Lead Software Engineer Nicolet Biomedical, a division of VIASYS Healthcare, Inc. 5225 Verona Rd. Bldg. #2 Madison, WI 53711 kevin.menningen@viasyshc.com http://www.viasyshealthcare.com