65
SYE (Subject) / SYE (Lesson)
Advertisement
- Template based text Requirement Requirements documented in natural language, following a syntax Example [If <condition>] THE SYSTEM <systemname> (SHALL|SHOULD|WILL) (<process verb> | ENABLE <whom?> TO <process verb> | BE ABLE TO < process verb>) <object> [<detail about the object>]
- Requirments Metadata Attributes o Requirement ID o Requirement Type o Requirements text o Rationale o Status of the content o Dependency Relations (for Traceability) o Verification Method o Validation Status o Author o Owner o Risk o Criticality o Priority o Stability
- Well written requirements o establish the basis for agreement between the stakeholders and the developers on what the product is to do o provide a basis for estimating costs and schedules o facilitate transfer (of results from one project to another) o serve as a basis for enhancement
- Requirements allocation o Requirements allocation means the association of requirements with nodes of the product breakdown structure o The highest Level Requirements are assigned to the system. o They are split up into more detailed requirements if possible o A requirement is allocated at the innermost subsystem where it is fully satisfied
- Three Dimensions of Requirements Engineering o Documentation – from informal to compliant with rules o Content – from vague to complete o Agreement – from individual views to consolidated views
- Requirement - Compliant with rules (what, why) o What - The requirements are documented (represented) according to the rules specified for the project. As an example the rules may state that requirements have to be represented by shall statements following a given template. o Why - Requirements should be “compliant with rules” to make them manageable. Only if they are expressed uniformly, it is possible to efficiently identify them, uniquely refer to them, search for them, communicate them, consistently change them, etc. during the product life cycle.
- should RE be phase-oriented? -RE should not be phase-oriented (this is the old view)-It should be continuous---Continuous requirements engineering means to keep a consistent set of interrelated requirements artifacts over the whole life cycle of one or more projects while allowing for changes at any level.
- Good requirements criteria o Clarity (are requirements clear and unambiguous?) o Completeness (are all requirements complete, are there any requirements missing?) o Compliance (are all requirements at the correct level? (e.g. system, segment, element, etc.) ) o (are they free of implementation specifics?) o Consistency (are the requirements stated consistently without contradicting themselves) o (is the terminology consistent with the user and sponsors ’s terminology?) o (is the terminology consistently used throughout?) o (are the key terms included in the project ‘s glossary?) o Traceability (Are all requirements needed?) o (Is each requirement necessary to meet the parent requirement?) o (are all requirements uniquely numbered?) o Correctness (is each requirement correct?) o Functionality (are described functions necessary and sufficient?) o Performance (are all required performance specifications and margins listed?) o (is each performance requirement realistic?) o Interfaces (are all external interfaces clearly defined?) o (are all internal interfaces clearly defined?) o (are all interfaces necessary, sufficient, and consistent with each other?) o Maintainability o Reliability o Verifiability/Testability o (are the requirements free of unverifiable terms?)
- 39 Requirements engineering core activities · Requirements Elicitation · Requirements Documentation · Requirements Negotiation Cross-sectional: Requirements management Requirements validation
- 40 FURPS Functionality Usability Reliability Performance Supportability
- Advertisement
- 41 PBS / WBS v Product Breakdown Structure v Work Breakdown Structure The WBS should contain the PBS
- 42 Verification – Validation Verification checks against a set of requirements “Did we build the system right?” Validation tries to check against the stakeholders expectations “Did we build the right system?” Verification Methods Analysis Inspection Demonstration Test
- 43 Subsystems A subsystem is an element of a system à Not all elements are subsystems. A subsystem evolves through a number of phase products into the end product.
- 44 Function task, action, or activity that must be performed to achieve desired outcome might be accomplished by one or more system elements
- 45 Risk Risk is defined as the combination of the probability that a program or project will experience an undesired event and the consequences, impact, or severity of the undesired event, were it to occur