Requirements modeling is carried out once the requirements and constraints for an area have been captured and analyzed, it is an important activity to ensure the consistency and completeness of the requirements. There are multiple ways to model functional, quality attributes and constraints. The appropriate approach to take will depend on the type of system and the organizational standards, in some cases they are domain specific modelling languages which are used. An important aspect of this is how to transform models of one type into another. Traceability is also an important aspect of this, as some projects will need to map the delivery of specific requirements to the component(s) that delivers it.


Architects are expected to be experienced with the different ways to model functional requirements, although on a project of any size it will usually be the responsibility of the analyst, the architect will need to have this capability to validate models which have been produced, especially to quickly identify the architecturally significant requirements. Architects may also have to model requirements for a specific area such as where a Proof of Concept is being produced early on, or for a technical area like operational management. Obviously the architect must be able to understand and interpret the requirements models to develop the architecture.

Depending on the organizations role definitions, or the analyst’s experience, the modelling of quality attributes will sometimes become the responsibility of the architect as they are reliant on understanding these due to their significant impact on producing an architecture which will meet the business need. This includes identifying and describing architectural trade-offs, which is covered by the capability: “Optimizing Quality Attributes”.

Proven Practices

There are many ways requirements can be modeled; some of the most common requirements models which are used include the following:

The Domain Model

The Domain Model captures all things (Domain Concepts) the product or system “deals with”, i.e. represents and manipulates from a business perspective. The information captured for a Domain Concept is a description and often as well properties and their relationship to each other. The purpose of the Domain Model is to establish a common understanding of the static aspects of the business domain amongst all stakeholders. The Domain Model supports the creation of quality requirements by establishing a common vocabulary across all stakeholders reducing ambiguity and redundancy.

As a result, the following guidelines should be considered:

  • The contents should be written in the business language of the domain and avoid implementation specific or technical aspects (such as operations or actions, which some presentations do not rule out): Use good business names!
  • Stakeholders should be comfortable with the chosen representation of the Domain Model (see below) in order to be able to provide feedback. As a result, multiple views on the domain model may be necessary for different stakeholders.
  • The domain model is developed in iterations where necessary details are enriched over time.

An obvious way to identify Domain Concepts is to identify nouns and phrases in textual descriptions of a domain. The information about the Domain Concepts can come from existing documentation, industry standard documents for a specific domain, and output from the requirements elicitation.

The Domain Model can be represented in different ways. The representation is dependent on the methodology and the formality employed in the project as well as the experience of the stakeholders exposed to the Domain Model. It can stretch from a Word document, an Excel table, diagrammatic representations to a fully detailed model representation using a UML class diagram.

The Domain Driven Design approach is an extension of the Domain Model to produce an implementation which is linked to an evolving model of the domain, it is appropriate for a highly complex domain and produces a highly maintainable system, the implementation can be by an Domain Specific Language.

The Use Case Model

A Use Case Model describes the proposed functionality of a new system. A Use Case represents a discrete unit of interaction between a user, called an Actor, (human or machine) and the system. This interaction is a single unit of meaningful work, such as Create Account or View Account Details. Each Use Case describes the functionality to be built in the proposed system, which can include another Use Case’s functionality or extend another Use Case with its own behavior.

The Use Case contains:

  • General comments and notes describing the use case.
  • Requirements – The formal functional requirements of things that a Use Case must provide to the end user, such as . These correspond to the functional specifications found in structured methodologies, and form a contract that the Use Case performs some action or provides some value to the system.
  • Constraints – The formal rules and limitations a Use Case operates under, defining what can and cannot be done. These include:
    • Pre-conditions that must have already occurred or be in place before the use case is run; for example, must precede
    • Post-conditions that must be true once the Use Case is complete; for example,
    • Invariants that must always be true throughout the time the Use Case operates; for example, an order must always have a customer number.
  • Scenarios – Formal, sequential descriptions of the steps taken to carry out the use case, or the flow of events that occur during a Use Case instance. These can include multiple scenarios, to cater for exceptional circumstances and alternative processing paths. These are usually created in text and correspond to a textual representation of the Sequence Diagram.
  • Scenario diagrams – Sequence diagrams to depict the workflow; similar to Scenarios but graphically portrayed.
  • Additional attributes, such as implementation phase, version number, complexity rating, stereotype and status.

The Use Case model shows how the Actors interact with the Use Cases.

Some other models used to capture functionality include:

  • Life Cycles – these are descriptions of the valid states in each Domain Concept’s “life”, along with the relationships between those states (e.g. legal transitions). It is important to note that such Life Cycles are related to a single Domain Concept (i.e. not to the system as a whole, one or more Use Cases, or the interaction of the system with the outside world ). Life Cycles are often referred to as State Machines or State Charts.
  • Business Process models – The use of Business Process Modelling (BPM) to represent the functionality of the enterprise is an alternative approach to developing software as fundamental concept is to develop the model in a tool which can then be used to produce an executable model. Each element has KPIs attached to it so it is frequently used as part of a performance improvement process.
  • User Stories – In agile projects user stories are used to capture requirements, these are short descriptions of how a particular user wants to interact with a system, in the form “As a I want to , so that . The user story includes a set of acceptance criteria which describe the boundary of the story and defines when it is done.
  • Traceability Matrix – To fill the need for traceability a traceability matrix can be produced. This can be as simple as a table which cross references the requirements to the software component that fulfills it, however this can become very hard to maintain, so it is more common to use a requirements management tools when this level of formality is required.


Software Development Life Cycle

Understand the various activities which are undertaken as part of requirements definition and how to represent these in the appropriate way for the project, using models. The ability to review requirements and ensure they are of high quality, namely:  unambiguous, concise, consistent, complete, implementable, verifiable, clear and testable.

Iasa Certification Level Learning Objective
CITA- Foundation
  • –          Learner will be able to name the main types of models used to capture requirements

    –          Learner will be able to name the key qualities for requirements

    –          Learner will be able to describe the different types of requirements produced by different user groups

    –          Learner will be able to review requirements produced and provide feedback on their quality.

    –          Learner will be able to point out gaps in requirements, not spotted by the analysts.

    –          Learner will be able to capture requirements for complex areas

    –          Learner will be able to support the analysts in capturing high quality requirements by introducing new techniques.


Development Technique and Tools

Architects will need to advise on the appropriate tools for each of the activities involved development and management of applications, for the areas which are the responsibility of the architect they are expected to be involved in their selection and usage. The architect will guide the project on issues such as adoption of modeling techniques, for example the use of UML. The architect will assist and mentor the development team with coding activities and will provide governance over the code review processes.

Iasa Certification Level Learning Objective
CITA- Foundation
  • Learner will be able to name the various types of tools and techniques used by the current organization and understand what they are used for
  • Learner will be involved in code reviews
CITA – Associate
  • Learner will be able to use a number of the tools and techniques
  • Learner will be able to carry out code reviews
  • Learner will be to identify the set of types of tools to be used
CITA – Specialist
  • Learner will be an expert in some of the tools and techniques and be able to highlight the advantages and disadvantages of each
  • Learner will be able to carry out code reviews on complex areas
CITA – Professional
  • Learner will be able to drive the introduction of new tools and technique into the organization
  • Learner will be able to act as a mentor for the tools and techniques
  • Learner will be involved in defining the code review process and the checklists to be used

Product Selection

Understand when it is appropriate use a COTS product to meet the business need, work with the project manager to define the process required for selection. Understand what changes are needed to the SDLC and ALM when the majority of the solution is provided by an external product.

Iasa Certification Level Learning Objective
CITA- Foundation
  • Learner will be able to name the activities involved in selecting a COTS product
  • Learner will be described the obvious cases where a COTS product should be selected and why
CITA – Associate
  • Learner will be describe how to carry out a COTS selection process using a weighted scoring process
  • Learner will be able to define the appropriate areas for COTS product consideration
CITA – Specialist
  • Learner will be able to define a weighted scoring process for a project including aspects of ALM
  • Learner will be able to be involved in negotiations with suppliers on the solution and how it will integrate with other systems
CITA – Professional
  • Learner will be able to define the changes to the existing SDLC and ALM when a COTS product is being used
  • Learner will be able to understand the sophisticated factors which influences product selection in an organization, including politics, alignment with strategy and risk profile

Measuring Application Development

The architect will facilitate improvements by changing approaches and working practices, this can be by identifying the key metrics on a project and ensuring they are correctly capture, this may involve issue tools such a JIRA and code analysis tools such as Sonar. In some organizations recognized models such as the Capability Maturity Model Integration (CMMI), the Software Process Improvement and Capability dEtermination model (SPICE), or COBIT may be used.

Iasa Certification Level Learning Objective
CITA- Foundation
  • Learner will be able to name the various types of measures and metric used in their organization
  • Learner will be able to name the commonly used models
CITA – Associate
  • Learner will be able identify some metrics to use on projects and how to measure them
  • Learner will be to define some problems with metrics
CITA – Specialist
  • Learner will be able to identify a coherent set of metrics to use in projects
  • Learners will be able to predict negative effects of measurement and devised ways to apply these which result in desired outcome
  • Learner will be able to define the models and describe how they are used
CITA – Professional
  • Learner will be able to define new metrics and improve the process as a consequence of measurement
  • Learner will be able to work with the stakeholders to understand how to define apply SLAs

Related Capabilities

Technical Project Management, especially Estimating


Blogs/Webcasts/News/Reference Sources

Background and description of Waterfall –

Agile approach –

All things CMMI –


Software Engineering a Practitioner’s Approach by Roger S Pressman, Darrel Ince. This provides an excellent background, does not cover agile methods.


For the agile approach using Scrum –