Book a Demo

Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Prev Next

Levels and Types of Requirements

There are many different types of requirement, ranging from high level business requirements down to detailed technical requirements that specify an intricate part of a computer algorithm or hardware device. There are also types based on the source of the requirement - such as stakeholder requirements - or the location in the process - such as transition requirements. There is often confusion and debate about exactly what constitutes a requirement, so some teams will define Business Rules and Policies as requirements and others will view them as business specifications. Regardless of the method or the process that is being followed, Enterprise Architect allows the analyst to create sophisticated models of all requirement types.

The Extended Requirement toolbox in Sparx Systems Enterprise Architect.

Business Requirements

Business Requirements are high-level requirements that express the objectives and desired outcomes of an organization. They are often disregarded as being 'fluffy' by engineers who cannot see how they would be implemented, but if they are articulated well they can be broken down to measurable statements. They are typically defined in a business case or other statements by the product owner or sponsor, the marketing department or the customer. They attempt to articulate why the organization is spending money and resources on the project. Enterprise Architect has a Business Requirement element available from the 'Requirements' toolbox page for this purpose.

Traceability through modeled Requirements in Sparx Systems Enterprise Architect.

Functional Requirements

Functional Requirements are the bridge between the business and technical teams and provide the definition of what the system must do for its users that will in turn meet the business goals. Some methodologists believe that Functional Requirements can be described using only Use Cases or User Stories, but this appears to be a purist view and in practice there seems to be a need for detailed textual Requirements that describe what the architect must design and the developer must implement. Enterprise Architect has a Functional Requirement element available from the 'Requirements' toolbox page. There is also an Architectural Requirement available from the 'Extended Requirements' page of the Requirements toolbox. In addition there is support for modeling Use Cases and Scenarios using the Scenario Builder.

Requirement hierarchy with external requirement in Sparx Systems Enterprise Architect

Stakeholder Requirements

Stakeholder Requirements are statements of the stakeholders' needs and expectations and describe the features that must be met if the business requirements are to be fulfilled. Analysts tend to focus on the functional aspects of the needs but stakeholders' expectations might include performance and reliability and a variety of other non-functional needs. Both are critical and act as precursors to the definition of the functional and non functional requirements that will be consumed by the designers and implementers to create solutions that meet the customer's expectations. Enterprise Architect has a Requirement element that can be stereotyped to <<stakeholder requirement>> available from the 'Requirements' toolbox page for this purpose.

Business Analysis with stereotyped requirements in Sparx Systems Enterprise Architect

Non Functional Requirements

Non-Functional Requirements and Quality Attributes describe how well a system will perform when it is operating. These typically define or constrain how the system should be behave as a whole and include attributes such as how well it performs, how secure it is, how many times it develops a fault and how easily it can be extended.

Performance requirements as quality attributes in Sparx Systems Enterprise Architect.

Transition Requirements

Transition Requirements define what is needed to transform the business and systems from the current state to the future state. They define a transitory situation and once the system has been fully implemented the requirements and their implementation will not be visible. They define things such as training, conversion and reformatting of data and parallel runs of business and technology systems.