INFO 627Lecture #101 Requirements Engineering and Management INFO 627 Review Glenn Booker.
-
Upload
adelia-jefferson -
Category
Documents
-
view
215 -
download
1
Transcript of INFO 627Lecture #101 Requirements Engineering and Management INFO 627 Review Glenn Booker.
INFO 627 Lecture #10 2
Verification Methods Test Demonstration Analysis Inspection Certification Similarity Not Applicable
INFO 627 Lecture #10 3
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.
INFO 627 Lecture #10 4
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.
INFO 627 Lecture #10 5
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.
INFO 627 Lecture #10 6
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.
INFO 627 Lecture #10 7
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.
INFO 627 Lecture #10 8
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
INFO 627 Lecture #10 9
Non-Functional Requirements Availability Maintainability Performance Portability Reliability Security Supportability Usability
Additional examples of, and resources for
INFO 627 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
INFO 627 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.
INFO 627 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
costNotice that “performance” can relate to the system’s performance,
or the developer’s performance in creating the system.
INFO 627 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
INFO 627 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
INFO 627 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.
INFO 627 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.
INFO 627 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
INFO 627 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
INFO 627 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
INFO 627 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
INFO 627 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
INFO 627 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
INFO 627 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
INFO 627 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
INFO 627 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!