Key Attributes of Requirements and Their Transformational Effects
Attributes of a Single Requirement
- Agreed: stakeholders established sufficient agreement about the requirement
- Atomic: the requirement describes only a single, coherent fact.
- Complete: does not omit any relevant information for some stakeholder and doesn’t need any further explanations.
- Feasible
- Rated (prioritized): each requirement must be ranked against others according to importance
- Verifiable
- Unambiguous
- Shall: (Required)
- Will: (Intention): prospective
- Should (Suggestion): strongly advised
- May: desirable but not necessary
Traceable: the source, evolution and use in later development phases of the requirement are identified and documented – if it is atomic and has a unique id, it’s usually traceable
Attributes for a Requirements Document
- Unambiguity
- Consistency
- Clear Structure
- Modifiability, Extensibility, Updateable: If you must change a requirement (create, edit or delete), you must be able to evaluate the impact of that change on all other requirements.
- Completeness
- Traceability: You must be able to tie a derived requirement back to its origin (source, specific stakeholder that request it during elicitation). You must be able to trace a requirement to the hardware/software that implements it, as well as to the test cases that verify it.
Transformational Effects:
Nominalization: using nouns instead of verbs turns (normally long lasting) processes into single events:
– “In case of a system crash, a restart of the system shall be performed”
– Consequence: loss of information necessary to describe the process (how shall the system be restarted?)
– Improved: “If the system crashes, the user shall restart the system using the reset button on the front”
Nouns without Reference Index: Vaguely specified nouns: “The data shall be displayed to the user on the terminal”
– Consequence: Missing information (which specific data?)
– Solution: amend requirements by additional information
– Improved: “The system shall display the billing data to the registered user on the terminal”
– Examples: the user, the controller, the system, the message, the data, the function
Universal Quantifiers: the use of universal quantifiers bears the risk of incorrect generalizations
– “The system shall process ALL input data”
– Consequence: even invalid data is processed
– Improved: the system shall process the valid input data according to the schema A2
– Examples: each, every, always, each time, in the evening, all, some, nothing, none
Incomplete Condition: specified conditions bear the risk that not all relevant cases are considered
– “The restaurant system shall offer all beverages to registered guests over the age of 20”
– Improved: (Cases: Age > 20; Age “The restaurant system shall offer alcohol-free beverages to any registered user younger than the age of 20”
– “The restaurant system shall offer all beverages including the alcoholic beverages to any user 21 years old and above”
Incomplete Process Verbs: some verbs require more than a noun in the sentence to consider a requirement as complete
– “To log a user in, the login data is entered” missing information: what login data? how is the data entered? who enters the data? Improved: “The system must allow the user to enter his username and password using the keyboard of the terminal”
– Types of Conflicts, (often the conflict reasons are mixed)
1. Subject conflict (data conflict): wrong (misinformation) or incomplete info about the req
2. Interest conflict: characterized by interests or goals(for system) that contradict each other
– Procedural interests
– Psychological interest
2. Value conflict: characterized by different way of life, ideology or religion, different criteria for evaluating ideas or behavior
3. Relationship conflict: characterized by strong emotions, deficient communication, negative interpersonal behavior between stakeholders
4. Structural conflict
– Characterized by unequal balance of authority or power
– Destructive patterns of interaction
– Unequal control, ownership or distribution of resources, time constraints, like superior rejects reqs from employee cuz he doesn’t recognize emp’s competence.
Resolution Techniques: (Negotiation, creative solution, decision)
Classification Traceability:
- Pre-RS-Traceability: T of req to origin is necessary, to demonstrate the reaching of goals and needs
- Post-RS-Traceability: to solution is necessary, to evaluate results of changes.
- Traceability between reqs is necessary, to manage dependencies between requirements (refinement, generalization, replacement)
– Created by, date created, last updated by, last revision date, related reqs
Change Control Board (CCB)
Classify incoming change requests, estimate effort for performing change, evaluate change requests with respect to effort/benefit ratio, define new or changed requirements, accept or reject change requests, prioritize accepted change requests, assign accepted change requests to change projects/releases
– Compose: change manager, contractor, architect, user rep, quality manager, requirements engineer
Classification of Incoming Change Requests:
- Corrective Requirement Change
– Failure during operation because of an error in the requirements
– Timely analysis, evaluation and eventually implemented - Adaptive Requirement Change
– Change in the context
– Grouped and analyzed, evaluated together later, an implemented in a (later) release - Exceptional Change (Hot Fix)
– Can be corrective or adaptive
– Must be absolutely immediately be done at all costs
Inspection: complete formal techniques with all roles, activities and use of checklists
Walkthrough: less preparation, no checklists, author present step by step, author is moderator
Classification of Finding:
- Good
- Critical Error
- Major Defect
- Minor Defect
- Open Issue
