Software Requirements: Functional and Non-Functional, User , System Requirements

Software Requirements: Functional and Non-Functional, User requirements, System requirements, Software Requirements Document

Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.

Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirements can be functional and non-functional.

Requirements engineering

Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the requirements, for instance.

Requirement engineering according to Laplante (2007) is "a subdiscipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of hardware and software systems." In some life cycle models, the requirement engineering process begins with a feasibility study activity, which leads to a feasibility report. If the feasibility study suggest that the product should be developed, then requirement analysis can begin. If requirement analysis precedes feasibility studies, which may foster outside the box thinking, then feasibility should be determined before requirements are finalized.

Requirements analysis topics

Stakeholder identification

See Stakeholder analysis for a discussion of business uses. Stakeholders (SH) are persons or organizations (legal entities such as companies, standards bodies) which have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:

•         anyone who operates the system (normal and maintenance operators)

•         anyone who benefits from the system (functional, political, financial and social beneficiaries)

•          anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing and sometimes sales act as surrogate consumers (mass-market customers) to guide development of the product

•         organizations which regulate aspects of the system (financial, safety, and other regulators)

•         people or organizations opposed to the system (negative stakeholders; see also Misuse case)

•         organizations responsible for systems which interface with the system under design

          those organizations who integrate horizontally with the organization for whom the analyst is designing the system

Types of Requirements

Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management:

Customer Requirements

Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:

•        Operational distribution or deployment: Where will the system be used?

•        Mission profile or scenario: How will the system accomplish its mission objective?

•        Performance and related parameters: What are the critical system parameters to accomplish the mission?

•        Utilization environments: How are the various system components to be used?

•        Effectiveness requirements: How effective or efficient must the system be in performing its mission?

•      Operational life cycle: How long will the system be in use by the user?

•      Environment: What environments will the system be expected to operate in an effective manner?

Functional Requirements

Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.

Non-functional Requirements

Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

Performance Requirements

The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.

Design Requirements

The ―build to,‖ ―code to,‖ and ―buy to‖ requirements for products and ―how to execute‖ requirements for processes expressed in technical data packages and technical manuals.

Derived Requirements

Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

Allocated Requirements

A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.

Well-known requirements categorization models include FURPS and FURPS+, developed at Hewlett-Packard.

Requirements analysis issues

Stakeholder issues

Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit requirements gathering:

•         Users do not understand what they want or users don't have a clear idea of their requirements

•         Users will not commit to a set of written requirements

•         Users insist on new requirements after the cost and schedule have been fixed

•         Communication with users is slow

•         Users often do not participate in reviews or are incapable of doing so

•         Users are technically unsophisticated

•         Users do not understand the development process

•         Users do not know about present technology

This may lead to the situation where user requirements keep changing even when system or product development has been started.