1. :: 1 :: What is a requirement? Standard Definition Something the product must do or a quality the product must have. More Ways to Characterize Something you discover BEFORE you build. Agreement reached between customer and developer on what the system will do.

2. :: 2 ::

3. :: 3 :: Size of the Problem 40 – 60% of errors in systems have been traced back to the requirements and analysis phase 70 – 85% of total revisions can be can be attributed to requirements errors [Leffingwell, 1997]

4. :: 4 :: Traditional Requirements Categories Business User Functional Non-functional Carnegie Mellon Software Engineering Institute

5. :: 5 :: Type of Requirement - Business Meaning What the organization hopes to achieve The business benefits that the product will offer Eliciting the business requirements – How will this product improve the business or organization? What will you be able to do that you cannot do now? Carnegie Mellon Software Engineering Institute

6. :: 6 :: Type of Requirement - User Meaning What the user requires to complete tasks Business rules, data representation requirements, logical models and acceptance criteria that the user will employ Eliciting the user requirements – Business processes within which tasks take place Tasks and task set definitions Required business rules? Deciding if the new system is working? Carnegie Mellon Software Engineering Institute

7. :: 7 :: Type of Requirement - Functional Meaning What the software system should do What it must do to have the desired impact on the outside domain Eliciting the functional requirements – Functional Req.# Priority (High if must have, Medium if desired, Low if nice to have) Description Related User Req.# Input Information Output Information Carnegie Mellon Software Engineering Institute

8. :: 8 :: Type of Requirement – Non- Functional Meaning Standards Regulations Constraints Interfaces Quality attributes that affect how the system must perform Examples Enterprise standards Government regulations Platform Legacy interfaces Usability Scalability Security Flexibility Portability Carnegie Mellon Software Engineering Institute

9. :: 9 :: Elements of a good requirement Necessary Feasible Verifiable Clear and Concise Complete Consistent Traceable No implementation bias Carnegie Mellon Software Engineering Institute

10. :: 10 :: Current State of Requirements Development in Public Health

11. :: 11 :: How the Client explained it How the Project Officer understood it How the Analyst designed it How the Programmer wrote it How the Sales Rep described it How the project was documented What operation installed How the Customer was billed How the project was supported What the Client really needed

12. :: 12 :: Contact Us Public Health Informatics Institute 750 Commerce Street, Suite 400 Decatur, GA 30030 dross@phii.org http://www.phii.org/