This activity follows upon approval by the stakeholders to continue a project after having completed the V1.Articulation, V2.Analysis, and after it has been confirmed in V2.Decision that a new functionality of the (ICT) systems may be required and can be built cost-effectively, i.e., they have confirmed that the new system is worth building.
The question that must be answered in the Requirements Workspace is: What do the owners and users need and want from the new system?
Requirements can be expressed in narrative, model, and prototype forms, or any combination thereof.
It is common to distinguish two kinds of requirements:
- A functional requirement is a description of activities and services a system must provide: inputs, outputs, processes, stored data.
- A nonfunctional requirement is a description of other features, characteristics, and constraints that define a satisfactory system: performance, ease of learning and use, budgets, deadlines, documentation, security, internal auditing controls.
Below the focus is on the following sub-activities: Expressing System Requirements, Prioritizing System Requirements, Support for Reuse and Incremental Design
Expressing System Requirements
To draft functional and nonfunctional requirements one could use a simple list of system improvement objectives.
Increasingly systems analysts express functional requirements using Use Cases. A Use case is a business scenario or event for which the system must provide a defined response. Use cases evolved out of object-oriented analysis; however, their use has become common in many other methodologies for systems analysis and design.
Prioritizing System Requirements
The prioritization of requirements can be facilitated using timeboxing.
Timeboxing is a technique that delivers information systems functionality and requirements through versioning.
The development team selects the smallest subset of the system that, if fully implemented, will return immediate value to the systems owners and users. That subset is developed, ideally with a time frame of six to nine months or less. Subsequently, value-added versions of the system are developed in similar time frames.
- A mandatory requirement is one that must be fulfilled by the minimal system, version 1.0
- A desirable requirement is one that is not absolutely essential to version 1.0. It may be essential to the vision of a future version.
Support for Reuse and Incremental Design
to be written
Description
| Name1 | name | ||||||||||||
| Domain | |||||||||||||
| Target Outcome | outcome | ||||||||||||
| Social actors and roles | roles | ||||||||||||
| Trigger or preceding interaction | prec | ||||||||||||
| Interfaces and services | services | ||||||||||||
| Inputs and outputs | i/o | ||||||||||||
| Stores and tools |
Regarding Content that is Accurate and Reliable, this will be part of Repository for partnerships (wikiworx). tools |
||||||||||||
| Other characteristics |
|
||||||||||||
| Further reading | ref |
- Questions, answers, comments
- "PE.V3-Requirements" among the interactions
- All interactions
- All events
- On the template