Главная Обратная связь

Дисциплины:






Different requirement types



A fundamental assumption here is that the analysis of the current and required business processes results in functional requirements met through IT services (comprising applications, data, infrastructure, environment and support skills).

It is important to note that there are commonly said to be three major types of requirements for any system – functional requirements, management and operational requirements, and usability requirements.

  • Functional requirements are those specifically required to support a particular business function.
  • Management and operational requirements (sometimes referred to as non-functional requirements) address the need for a responsive, available and secure service, and deal with such issues as ease of deployment, operability, management needs and security.
  • Usability requirements are those that address the ‘look and feel’ needs of the user and result in features of the service that facilitate its ease of use. This requirement type is often seen as part of management and operational requirements, but for the purposes of this section it will be addressed separately.

5.1.1.1 Functional requirements

Functional requirements describe the things a service is intended to do, and can be expressed as tasks or functions that the component is required to perform. One approach for specifying functional requirements is through such methods as a system context diagram or a use case model. Other approaches show how the inputs are to be transformed into the outputs (data flow or object diagrams) and textual descriptions.

A system context diagram, for instance, captures all information exchanges between, on the one hand, the IT service and its environment and, on the other, sources or destinations of data used by the service. These information exchanges and data sources represent constraints on the service under development.

A use case model defines a goal-oriented set of interactions between external actors and the service under consideration. Actors are parties outside the service that interact with the service. An actor may reflect a class of user’s roles that users can play, or other services and their requirements. The main purpose of use case modelling is to establish the boundary of the proposed system and fully state the functional capabilities to be delivered to the users. Use cases are also helpful for establishing communication between business and application developers. They provide a basis for sizing and feed the definition of usability requirements. Use cases define all scenarios that an application has to support and can therefore easily be expanded into test cases. Since use cases describe a service’s functionality on a level that’s understandable for both business and IT, they can serve as a vehicle to specify the functional elements of an SLA, such as the actual business deliverables from the service.



One level ‘below’ the use case and the context diagram, many other modelling techniques can be applied. These models depict the static and dynamic characteristics of the services under development. A conceptual data model (whether called object or data) describes the different ‘objects’ in the service, their mutual relationships and their internal structure. Dynamics of the service can be described using state models (e.g. state transition diagrams) that show the various states of the entities or objects, together with events that may cause state changes. Interactions between the different application components can be described using interaction diagrams (e.g. object interaction diagrams). Alongside a mature requirements modelling process, CASE tools can help in getting and keeping these models consistent, correct and complete.

5.1.1.2 Management and operational requirements

Management and operational requirements (or non-functional requirements) are used to define requirements and constraints on the IT service. The requirements serve as a basis for early systems and service sizing and estimates of cost, and can support the assessment of the viability of the proposed IT service. Management and operational requirements should also encourage developers to take a broader view of project goals.

Categories of management and operational requirements include:

  • Manageability: Does it run? Does it fail? How does it fail?
  • Efficiency: How many resources does it consume?
  • Availabilityandreliability: How reliable does it need to be?
  • Capacityandperformance: What level of capacity do we need?
  • Security: What classification of security is required?
  • Installation: How much effort does it take to install the application? Is it using automated install procedures?
  • Continuity: What level of resilience and recovery is required?
  • Controllability: Can it be monitored, managed and adjusted?
  • Maintainability: How well can the application be adjusted, corrected, maintained and changed for future requirements?
  • Operability: Do the applications disturb other applications in their functionalities?
  • Measurability and reportability: Can we measure and report on all of the required aspects of the application?

The management and operational requirements can be used to prescribe the quality attributes of the application being built. These quality attributes can be used to design test plans for testing the applications on the compliance to management and operational requirements.

5.1.1.3 Usability requirements

The primary purpose of usability requirements is to ensure that the service meets the expectations of its users with regard to its ease of use. To achieve this:

  • Establish performance standards for usability evaluations
  • Define test scenarios for usability test plans and usability testing.

Like the management and operational requirements, usability requirements can also be used as the quality attributes of design test plans for testing the applications on their compliance to usability requirements.

5.1.2 Requirements for support – the user view

Users have formally defined roles and activities as user representatives in requirements definition and acceptance testing. They should be actively involved in identifying all aspects of service requirements, including the three categories above, and also in:





sdamzavas.net - 2020 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...