Requirement Engineering

the process of esstablishing the services that the customer requires from a system and the contraints under which it operates and is developed

= description of

• the system service

• and contraints

• from a high level abstract statement

• to a detailed mathematical functional specification

• Statements of service the system should provide, how the system should react to particular inputs and how the system should behave in particular situations

• may state what the system should not do

• constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

• often apply to the system as a whole rather than individual features or services

contraints on the system from the domain of operation

• non functional requirements may be more critical than functional requirements

  • if these are not met, the system may be useless

• non functional requirements may affect the overall architecture of a system

  • rather then individual components

  • cross-cutting concern

• a single non functional requirement

  • may generate a number of related funtional requirements

  • and may also generate requirements that restrict existing requ.

• properties: reliability, response time and storage requirements

• contraints: I/O device capability, system representation, etc

if these are not met, the system may be useless

• elication

• documentation

• validation

• management

• tracebility

• change management

• verification

the process of writing down the user and system requirements in a requirement document

• Validity: system provides function which best support customer’s needs?

• Consistency: any requ. conflicts?

• Completeness: all functions required by customer given?

• Realism: can it be implemented with given budget and technology?

• Verifiability: can it be checked?

• Requirements reviews

• Prototyping

• Test-case generation

• the business and technical environment of the system always changes after istallation

• people who pay for a system and the users of that system are rarely the same people

• large systems usually have a divers user community, with many users having different requirements and priorities that may be conflicting or contradictiory

process of managing changing requirements during the requirement engineering process and system developement

• requirements identification

• a change management process

• traceability policies

• tool support

• problem analysis and change specification

• change analysis and costing

• change implementation

an agreed statement of the system requirements

• requirement elication

• specification

• validation

• Complete, Consistent, Correct

• Unambigious

• Verifiable

• Traceable

• Ranked for importance and/or stability

• Modifiable

• Definiton of the response of the software to all realizable classes of input data in all realizable classes of situations

• All possible situations must be covered

• a software requirement is unambigious, if and only if, every requirement stated therein

• internally consistent if, and only if, no subset of individual requirements described in is conflict

• specific characteristic of real-world objects

• the logical or temporal conflict between two actions

• different termns for describing the same real-world object

in general case, we need a complete overview of all requirements that are related to the same event, function, or parameter

• forward referencing

• opacity

• noise

• etc.

requirement item that make use of problem world domain features that are not yet defined

• requirement items for which rational or dependencies are invisible

• requirement item that yield no information on problem world features

• how test-friendly is the requirement?

• How easy is it to test the implementation?

-> these are not independant

• executing a test

• run experiments

• inspect the code and other artifacts

• stated in precise way

• for some, this is in place right from the start

• for some other, we need to change it to get a testable version

• modifying phrases

• vague words

• pronounds with no reference

• passive voice

• negative requirements

• assumptions and comparisons

• idefinite pronouns

• bounary values

• …

• autonomy of the system under test

• observability of the testing progress

• re-test efficiency

• test restartability

• how easy is it to observe the progress of the test execution?

• how easy to observe results of the test?

• stop the test temporarily

• study current stare and output

• start the test again from the point where it was stopped

• maturaty: MTTF (mean time to failure, expected time to failure for a non-repairable system) >500hr

• availibility: systme shall meet or exceed 99.99% uptime

• recoverability: in case of error, time needed to get system up and running again MTTR shall not exceed one hour

• effectiveness

• efficiency

• satisfaction

• source of the requirement

• requirement

• work product that implement the requirements

• work products that implement the Requirements

• Requirements

• Source of the Requirements

• ensure all requirements are implemented

• change impact analysis

• avoid “gold plating”

• change impact analysis

• defect impact analysis

• root cause analysis of defects

if and only if, a requirment structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining the strucutre and style

• redundancy can easily lead to low modifiability

• boilerplate can help improve modifiability: e.g. will -> shall