info 627lecture #101 requirements engineering and management info 627 review glenn booker

INFO 627 Lecture #10 1

Requirements Engineeringand ManagementINFO 627

Review

Glenn Booker


Verification Methods Test Demonstration Analysis Inspection Certification Similarity Not Applicable


Verification MethodsTest: 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.


Verification MethodsDemonstration: 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.


Verification MethodsAnalysis: 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.


Verification MethodsInspection: 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.


Verification MethodsCertification: 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.


Verification MethodsNot 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


Non-Functional Requirements Availability Maintainability Performance Portability Reliability Security Supportability Usability

Additional examples of, and resources for


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


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.


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

costNotice that “performance” can relate to the system’s performance,

or the developer’s performance in creating the system.


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


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


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.


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.


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


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


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


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


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


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


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


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


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!

info 627lecture #101 requirements engineering and management info 627 review glenn booker

Documents