All notes
RequirementManagem

# Requirements management

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.[4] 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.

## Investigation

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.

## Feasibility

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.

## Wireframe

• Axure
• 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，生成规范的文档。

# Software Requirement Specification

It lays out functional and non-functional requirements, and may include a set of use cases that describe user interactions that the software must provide.

The Software Requirements Specification (SRS) is:

• A communication tool between stakeholders and software designers, such as customers and contractors or suppliers, or in market-driven projects, these roles may be played by the marketing and development divisions.
• A realistic basis for estimating product costs, risks, and schedules
• Describing the Scope Of Work (business record of agreement).
• Providing a reference to software designers (i.e. navigation aids, document structure).
• Providing a framework for testing primary and secondary use cases.
• Linking features to customer requirements.
• Providing a platform for ongoing refinement (via incomplete specs or questions).

An example organization of an SRS is as follows:

Introduction
Purpose
Definitions
System overview
References
Overall description
Product perspective
System Interfaces
User Interfaces
Hardware interfaces
Software interfaces
Communication Interfaces
Memory Constraints
Operations
Product functions
User characteristics
Constraints, assumptions and dependencies
Specific requirements
External interface requirements
Functional requirements
Performance requirements
Design constraints
Standards Compliance
Logical database requirement
Software System attributes
Reliability
Availability
Security
Maintainability
Portability
Other requirements


Wcf's template:

Introduction
Purpose
Definitions
System overview
References
Overall description
Product perspective
System Interfaces
User Interfaces
Hardware interfaces
Software interfaces
Communication Interfaces
Memory Constraints
Operations
Product functions
User characteristics
Constraints, assumptions and dependencies
Specific requirements
External interface requirements
Functional requirements
Performance requirements
Design constraints
Standards Compliance
Logical database requirement
Software System attributes
Reliability
Availability
Security
Maintainability
Portability
Other requirements


# Configure management

## Intro

Wikipedia. In software engineering, software configuration management (SCM or S/W CM) is the task of tracking and controlling changes in the software.
SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine what was changed and who changed it.

Wikipedia. In configuration management, a "baseline" is an agreed description of the attributes of a product, at a point in time, which serves as a basis for defining change.

## Environments

• dev: Working code copy. Changes made by developers are deployed here so integration and features can be tested. This environment is rapidly updated and contains the most recent version of the application.
• qa: (Only big companies will have this) Environment for quality assurance. This provides a less frequently changed version of the application which testers can perform checks against. This allows reporting on a common revision so developers know whether particular issues found by testers has already been corrected in the development code.
• staging: This is the release candidate, and this environment is normally a mirror of the production environment. The staging area contains the "next" version of the application and is used for final stress testing and client/manager approvals before going live.
• production: This is the currently released version of the application, accessible to the client/end users. This version preferably does not change except for during scheduled releases.