Requirements Engineering and Management INFO 627

1. Requirements Engineeringand ManagementINFO 627 Review Glenn Booker Lecture #10

2. Verification Methods • Test • Demonstration • Analysis • Inspection • Certification • Similarity • Not Applicable Lecture #10

3. Verification Methods Test: Verification by test involves operation of the system and requires instrumentation for recording and evaluation of quantitative data. Acceptability of the item is determined by a comparison of the data with the specified quantitative parameters and tolerances. Lecture #10

4. Verification Methods Demonstration: Verification by demonstration involves operation of the system and requires evaluation of functional responses. Acceptability of the item is determined by a qualitative comparison of the data with the specified functional performance. Lecture #10

5. Verification Methods Analysis: Verification by analysis involves mathematical and/or analytical examination of the system design or test data. Acceptability of the item is determined by a comparison of the analytical results with the specified performance. Lecture #10

6. Verification Methods Inspection: Verification by inspection involves physical and visual measurements or examinations made under fully controlled and traceable conditions. Acceptability of the item is determined by a comparison of the data with the specified requirements. Lecture #10

7. Verification Methods Certification: Verification that a specification requirement is met by a documented certification of compliance. Similarity: Verification by similarity will be allowed in lieu of the other verification methods for products previously qualified. This will require evidence of product similarity as well as documented test results that prove the requirements were met. Lecture #10

8. Verification Methods Not Applicable: Verification is not required because the specification paragraph is a heading, title, or general introduction paragraph containing no specific “shall” requirements. • Used for completeness to show that every paragraph of the requirements document was accounted for Lecture #10

9. Availability Maintainability Performance Portability Reliability Security Supportability Usability Additional examples of, and resources for Non-Functional Requirements Lecture #10

10. Availability • The operational availability of the system shall not be less than 0.96 (threshold) and 0.98 (objective) in the environments specified in paragraph blah. • System shall have no more than 5 minutes of malfunctions per year. • Operational Availability = (UT)/(UT+MT) where UT = system up time, and MT = system maintenance (down) time Lecture #10

11. Maintainability • Operations staff shall be alerted to each unit failure within 30 seconds of its detection. • The data processors shall be capable of having, memory added (through modification, addition, or replacement) to attain a 200 percent greater memory capacity than the base resource requirement. • All components, assemblies, subassemblies, and modules that are identical with respect to fit, form, and function shall be interchangeable. Lecture #10

12. Performance • Response times, delivery times, timeliness – meeting deadlines or due dates, adherence to schedule • Error rates – number of mistakes/errors allowed in meeting the performance standard • Accuracy rates – similar to error rates, but most often stated in terms of percentages • Completion milestone rates – x% complete at a date • Cost control – keeping within the estimated cost or target cost Notice that “performance” can relate to the system’s performance, or the developer’s performance in creating the system. Lecture #10

13. Portability • Software portability refers to the ability to run application on different platforms or with different applications • Use of open standards supports portability • Define specific format standards for exchange of information Lecture #10

14. Reliability • All mission critical systems shall be designed to be two-fault tolerant. • The system shall provide the capability for automatic switchover to available backup components where failure of an element would cause loss of mission. • Mean Time Between Failures • Mean Time Between Maintenance Actions Lecture #10

15. Security • The system shall source-authenticate all incoming commands. • The system shall not accept invalid commands, noise, or spoofing as valid commands. • Commands that fail authentication shall not be executed. • Any element that processes multiple security levels of data should comply with DOD 5200.28-STD, Para. 3.1.1.3. Lecture #10

16. Supportability • Define skill level or job category of people who will maintain the system • System support will be consistent with: a single Operational Support Facility which provides engineering, operations support, and software systems maintenance; a single depot which provides central repair and reprocurement services; and a separate supply depot for each principal user. Lecture #10

17. Usability • Define requirements for use of the system by seeing or hearing challenged people • Define requirements for use of the system by people who don’t have typical anatomy • Software shall not interfere with existing features of other products or operating systems that affect the usability for people with disabilities • Require compliance with accepted standards for interface design Lecture #10

18. Where to Begin? • We started by recognizing that the software industry does terribly at developing stuff on time and within budget, often because requirements are poorly managed • To avoid this, we define the need for a requirements management process, with emphasis on customer agreement on the nature of the requirements Lecture #10

19. Team Skill 1 • The first skill was to understand the problem to be solved • Define the problem • Look for its root causes • Identify relevant stakeholders and users • Define system boundaries • Understand constraints on the solution Lecture #10

20. Team Skill 2 • The second skill was to understand user needs, in part by avoid three syndromes • “Yes, But…”, Undiscovered Ruins, User vs. the Developer • Extract requirements using seven skills: • Interviewing, workshops, brainstorming, storyboarding, use cases, role playing, and/or prototyping Lecture #10

21. Team Skill 3 • Next skill was to define the system • Defined hierarchy to help understand the system: • Needs, features, and requirements • Define the Vision for the system • Identify a champion for the Vision, to help keep it from drifting Lecture #10

22. Team Skill 4 • Once the requirements have been initially defined, we need to manage their scope • Identify priorities for requirements, and assign them to a baseline and later releases • If using incremental development • Negotiate scope changes (cost/time/features) • Select an appropriate life cycle model to help guide the project Lecture #10

23. Team Skill 5 • Now we can refine the system definition • Capture requirements and constraints in a Software Requirements Specification (SRS) • Including suitable high level models, use cases • Gave two structures from which to choose • Need development to implement the SRS, only the SRS, and the whole SRS Lecture #10

24. Team Skill 6 • Finally we need to build the right system • Inspect, trace, and test to verify that the actual system meets the requirements • Validate the correctness of the system to meet user needs, including user testing • Might use risk analysis to decide how much verification and validation are needed where • Define and use a change control process Lecture #10

25. Easy, right? • Capturing and implementing requirements is a tricky business, since it means communicating with *ugh* people • No magic pill can absolutely guarantee that your system will ultimately result in a happy customer, but we have covered a lot of techniques which can certainly make it lot more likely! Lecture #10