Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.
The requirements document becomes a critical tool that helps the team make decisions about design changes.
What makes a good requirement
- Verification: All requirements should be verifiable. For example, "the system must never or always exhibit a particular property", proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. For another example, A non-functional requirement to be free from backdoors may be satisfied by replacing it with a process requirement to use pair programming.
There is an engineering trade off to consider between requirements which are too vague, and those which are too detailed. Agile approaches evolved as a way of overcoming these problems, by baselining requirements at a high-level, and elaborating detail on a just-in-time or last responsible moment basis.
When iterative methods of software development or agile methods are used, the system requirements are incrementally developed in parallel with design and implementation.
Types of requirements
- Architectural requirements. Architectural requirements explain what has to be done by identifying the necessary systems structure and systems behavior, i.e., systems architecture of a system.
- Business requirements. High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities that an organization wants to realise or problems that they want to solve. Often stated in a business case.
- User (stakeholder) requirements. Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the high-level business requirements and more detailed solution requirements.
- Functional (solution) requirements. Usually detailed statements of capabilities, behaviour, and information that the solution will need. Examples include formatting text, calculating a number, modulating a signal. They are also known as capabilities.
- Quality-of-service (non-functional) requirements. Usually detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. Examples include: reliability, testability, maintainability, availability. They are also known as characteristics, constraints or the ilities.
- Implementation (transition) requirements. Usually detailed statements of capabilities or behaviour required only to enable transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required. Examples include: recruitment, role changes, education, migration of data from one system to another.
Requirement management in each step
Requirement management exists in all steps of a standard five-phase development process: Investigation, Feasibility, Design, Construction and Test, and Release stages.
In Investigation, the first three classes of requirements are gathered from the users, from the business and from the development team.
In each area, similar questions are asked; what are the goals, what are the constraints, what are the current tools or processes in place, and so on. Only when these requirements are well understood can functional requirements be developed.
The deliverable from the Investigation stage is a requirements document that has been approved by all members of the team.
As the system develops, each new feature opens a world of new possibilities, so the requirements specification anchors the team to the original vision and permits a controlled discussion of scope change.
The deliverable from the Feasibility stage is the budget and schedule for the project.
Construction and Test
A main tool used in this stage is prototype construction and iterative testing.
- POP（Prototyping on Paper）. Running on mobile, which is good.
- JustInMind. JustinMind是由西班牙JustinMind公司出品的原型制作工具，可以输出Html页面。与目前主流的交互设计工具axure，Balsamiq Mockups等相比，Justinmind Prototyper更为专属于设计移动终端上app应用。JustinMind 可以帮助开发者设计更丰富、更具交互新的移动产品线框图，包含了iPhone、Android 以及iPad常用手势，滑动、缩放、旋转，甚至捕捉设备方向等，从而创造出更具交互性的原型。另外，它可以导出原型信息到Microsoft Word，生成规范的文档。