INFO 627Lecture #101 Requirements Engineering and Management INFO 627 Review Glenn Booker

INFO 627Lecture #102 Verification Methods  Test  Demonstration  Analysis  Inspection  Certification  Similarity  Not Applicable

INFO 627Lecture #103 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.

INFO 627Lecture #104 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.

INFO 627Lecture #105 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.

INFO 627Lecture #106 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.

INFO 627Lecture #107 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.

INFO 627Lecture #108 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

INFO 627Lecture #109 Non-Functional Requirements  Availability  Maintainability  Performance  Portability  Reliability  Security  Supportability  Usability Additional examples of, and resources for

INFO 627Lecture #1010 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

INFO 627Lecture #1011 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.

INFO 627Lecture #1012 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.

INFO 627Lecture #1013 Portability  Software portability refers to the ability to run application on different platforms or with different applicationsportability Use of open standards supports portabilityopen standards  Define specific format standards for exchange of information

INFO 627Lecture #1014 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

INFO 627Lecture #1015 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 STD, Para DOD STD

INFO 627Lecture #1016 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.

INFO 627Lecture #1017 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 anatomyrequirements 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

INFO 627Lecture #1018 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

INFO 627Lecture #1019 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

INFO 627Lecture #1020 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

INFO 627Lecture #1021 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

INFO 627Lecture #1022 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

INFO 627Lecture #1023 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

INFO 627Lecture #1024 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

INFO 627Lecture #1025 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!