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”.

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.

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.

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.

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.

Technical Project Management, especially Estimating

Blogs/Webcasts/News/Reference Sources

Background and description of Waterfall – http://www.dcs.bbk.ac.uk/~sven/cdm06/cdm3.pdf

Agile approach – http://www.agilemodeling.com/

All things CMMI – https://www.sei.cmu.edu/cmmi/

Articles

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

Certifications 

For the agile approach using Scrum – http://www.scrumalliance.org/