Steps to define Architecture

Steps to define Architecture

  • Identify Stakeholders (to communicate with);

  • Understand the Problem, Functional Requirements (solve a valid business problem or have a recognizable return on investment (ROI));

  • Identify Design Elements and their Relationships (boundaries and context of the system);

  • Evaluate the Architecture Design (Non-Functional Requirements, quality attributes, constraints);

  • Prioritize quality attributes (trade-off analysis, suffer ones for others);

  • Transform the Architecture Design (quality attributes oriented - optimization of solutions using various patterns);

  • Document the results (to facilitate communication between stakeholders).

Identify stakeholders

A good place to start is by creating a typical list of stakeholders. This will vary according to the industry or scope of the project, but a typical stakeholder list would include:

  • Customers

  • Customers’ customers

  • Users

  • Developers

  • Marketers

  • Product Managers

  • Testers

  • Authorities/regulators

  • Laws/company lawyers

This list can help you to identify stakeholders, stakeholders are different for every system, you will need to conduct a stakeholder analysis. We like to carry this out in the form of a facilitated workshop.

Your participants in the workshop might include people who were involved in a feasibility study or representatives from both the client and the system provider.

The following steps should be done:

  • Write the name of the project or system in a circle in the middle of a whiteboard.

  • Let the participants brainstorm all the possible stakeholders. They should write the name, role, or organization of each stakeholder on a post-it-note and place it on the whiteboard around the circle.

  • Draw an arrow between each stakeholder and the project.

  • Divide the participants into groups and distribute the stakeholders between the groups.

  • Give the groups around 30 minutes to discuss what each stakeholder gets or requires from the project, and what the project needs from or gets from the stakeholder.

  • After 30 minutes the groups should present their findings. Write down what the stakeholder requires or receives from the project on one end of the arrow, closest to the stakeholder, and what the project requires or receives from the stakeholder at the other end, near the project.

  • After all the groups have presented their findings and your workshop is complete, you will have produced the material for a table similar to the one below.

Understand the Problem

Clearly defined requirements are essential signs on the road that leads to a successful project. They establish a formal agreement between a client and a provider that they are both working to reach the same goal. High-quality, detailed requirements also help mitigate financial risks and keep the project on a schedule.

Requirements classification:

  • Business requirements. These include high-level statements of goals, objectives, and needs.

  • Stakeholder requirements. The needs of discrete stakeholder groups are also specified to define what they expect from a particular solution.

  • Solution requirements. Solution requirements describe the characteristics that a product must have to meet the needs of the stakeholders and the business itself.

  • Nonfunctional requirements describe the general characteristics of a system. They are also known as quality attributes.

  • Functional requirements describe how a product must behave, what its features and functions.

  • Transition requirements. An additional group of requirements defines what is needed from an organization to successfully move from its current state to its desired state with the new product.

Requirements are usually written in text, especially for Agile-driven projects. However, they may also be visuals. Here are the most common formats and documents:

  • Software requirements specification document

  • Use cases

  • User stories

  • Work Breakdown Structure (WBS) (functional decomposition)

  • Prototypes

  • Models and diagrams

Functional requirements

The definition is: “Any Requirement Which Specifies What The System Should Do.”

In other words, a functional requirement will describe a particular behavior of function of the system when certain conditions are met, for example: “Send email when a new customer signs up” or “Open a new account”. A functional requirement for an everyday object like a cup would be: “ability to contain tea or coffee without leaking”.

Basically functional requirements can be divided into 4 groups which are:

  • Business requirements. They contain the ultimate goal, such as an order system, an online catalogue, or a physical product. It can also include things like approval workflows and authorization levels.

  • Administrative functions. They are the routine things the system will do, such as reporting.

  • User requirements. They are what the user of the system can do, such as place an order or browse the online catalogue.

  • System requirements. These are things like software and hardware specifications, system responses, or system actions.

Some of the more typical functional requirements include:

  • Business Rules

  • Transaction corrections, adjustments and cancellations

  • Administrative functions

  • Authentication

  • Authorization levels

  • Audit Tracking

  • External Interfaces

  • Certification Requirements

  • Reporting Requirements

  • Historical Data

  • Legal or Regulatory Requirements

Functional Requirements Example:

  1. Authentication of a user when he/she tries to log into the system.

  2. System shutdown in the case of a cyber-attack.

  3. Verification email is sent to user whenever he/she registers for the first time on some software system.

What are non-functional requirements?

The definition is: “Any Requirement That Specifies How The System Performs A Certain Function.

In other words, a non-functional requirement will describe how a system should behave and what limits there are on its functionality. Non-functional requirements specify the system’s ‘quality characteristics’ or ‘quality attributes’.

Non-functional requirements cover all the remaining requirements which are not covered by the functional requirements. They specify criteria that judge the operation of a system, rather than specific behaviors, for example: “Modified data in a database should be updated for all users accessing it within 2 seconds.” A non-functional requirement for the cup mentioned previously would be: “contain hot liquid without heating up to more than 45°C”.

Some typical non-functional requirements are:

  • Performance – for example, Response Time, Throughput, Utilization, Static Volumetric

  • Scalability - As needs grow, can the system handle it? For physical installations, this includes spare hardware or space to install it in the future.

  • Capacity

  • Availability - What are the uptime requirements? Does it need to function 24/7/365?

  • Reliability - How often does the system experience critical failures?

  • Recoverability

  • Maintainability - defines the time required for a solution or its component to be fixed, changed to increase performance or other qualities, or adapted to a changing environment

  • Supportability - Is support provided in-house or is remote accessibility for external resources required?

  • Security - What are the security requirements, both for the physical installation and from a cyber perspective?

  • Portability- Which hardware, operating systems, browsers, and their versions does the software run on?

  • Compatibility - Does it conflict with other applications and processes within these environments?

  • Localization. Does the system match local specifics?

  • Regulatory

  • Manageability

  • Environmental

  • Data Integrity

  • Usability - This focuses on the appearance of the user interface and how people interact with it. (What color are the screens? How big are the buttons?)

  • Interoperability

Non-functional Requirements Example:

  1. Emails should be sent with a latency of no greater than 12 hours.

  2. Each request should be processed within 10 seconds.

  3. The site should load in 3 seconds when the number of simultaneous users are > 10000

Difference between functional and non-functional requirements

The difference is that non-functional requirements describe how the system works, while functional requirements describe what the system should do.

Functional Requirements

Non-Functional Requirements

They define a system or its component.

They define the quality attribute of a system

It specifies, “What the system should do?”

It specifies, “How should the system fulfill the functional requirements?”

User specifies functional requirements.

Non-functional requirement is specified by technical peoples e.g. Architect, Technical leaders and software developers.

It is mandatory to meet these requirements.

It is not mandatory to meet these requirements.

It is captured in use case.

It is captured as a quality attribute.

Defined at a component level.

Applied to a whole system.

Helps you to verify the functionality of the software.

Helps you to verify the performance of the software.

Functional Testing like System, Integration, End to End, API testing, etc are done.

Non-Functional Testing like Performance, Stress, Usability, Security testing, etc are done.

Usually easy to define.

Usually more difficult to define.

Prioritize quality attributes

Document the results

How to write requirements?

Here are the most common formats and documents:

  • Software requirements specification document

  • Work Breakdown Structure (WBS) (functional decomposition)

  • User stories

  • Use cases

  • Prototypes

  • Models and diagrams

There are different ways to write functional and non-functional requirements.

Software requirements specification document

The most common way to write functional and non-functional requirements is through a Requirements Specification Document. It is a written description of the required functionality.

It states the project objective and includes an overview of the project to provide context, along with any constraints and assumptions. The requirements specification document is should include visual representations of the requirements to help non-technical stakeholders understand the scope.

SRS must include the following sections:

  • Purpose. Definitions, system overview, and background.

  • Overall description. Assumptions, constraints, business rules, and product vision.

  • Specific requirements. System attributes, functional requirements, database requirements.

Work Breakdown Structure (WBS)

Closely related to a requirements specification document is a Work Breakdown Structure or WBS. This breaks down the entire process into its components by “decomposing” the requirements into their elements until they cannot be broken down any further.

A functional decomposition or Work Breakdown Structure (WBS) is a visual document that illustrates how complex processes break down into simpler components until they cannot be broken down any further. WBS is an effective approach to allow for an independent analysis of each part. WBS also helps capture the full picture of the project.

We suggest the following logic of functional decomposition:

  1. Find the most general function.

  2. Find the closest sub function.

  3. Find the next level of sub function.

  4. Check your diagram.

The decomposition process may look like this: High Level Function -> Sub-function -> Process -> Activity

The features should be decomposed to the point at which the lowest level parts can’t be broken down any further.

User stories

Another approach is User Stories. They describe the functionality from the perspective of the end-user and states exactly what they want the system to do.

It effectively states “As a <type of user>, I want <goal> so that <reason>”. One benefit of user stories is that they do not require much technical knowledge to write. User stories can also be used as a precursor to a requirements specification document by helping define user needs. In Agile projects, user stories are organized in a backlog, which is an ordered list of product functions. Currently, user stories are considered to be the best format for backlog items.

A typical user story is written like this:

As a <type of user>, I want <some goal> so that <some reason>.

Example: As an admin, I want to add descriptions to products so that users can later view these descriptions and compare the products.

User stories must be accompanied by acceptance criteria. These are the conditions that the product must satisfy to be accepted by a user, stakeholders, or a product owner. Each user story must have at least one acceptance criterion. Effective acceptance criteria must be testable, concise, and completely understood by all team members and stakeholders. They can be written as checklists, plain text, or by using Given/When/Then format.

Example:

  • A search field is available on the top-bar.

  • A search is started when the user clicks Submit.

  • The default placeholder is a grey text Type the name.

  • The placeholder disappears when the user starts typing.

  • The search language is English.

  • The user can type no more than 200 symbols.

  • It doesn’t support special symbols. If the user has typed a special symbol in the search input, it displays the warning message: Search input cannot contain special symbols.

Finally, all user stories must fit the INVEST quality model:

  • IIndependent (This means that you can schedule and implement each user story separately. This is very helpful if you implement continuous integration processes.)

  • NNegotiable (This means that all parties agree to prioritize negotiations over specification. This also means that details will be created constantly during development.)

  • VValuable (A story must be valuable to the customer. You should ask yourself from the customer’s perspective “why” you need to implement a given feature.)

  • EEstimable (A quality user story can be estimated. This will help a team schedule and prioritize the implementation. The bigger the story is, the harder it is to estimate it.)

  • SSmall (Good user stories tend to be small enough to plan for short production releases. Small stories allow for more specific estimates)

  • TTestable (If a story can be tested, it’s clear enough and good enough. Tested stories mean that requirements are done and ready for use.)

Use cases

Use Cases are similar to user stories in that no technical knowledge is necessary. Use cases simply describe in detail what a user is doing as they execute a task. A use case might be “purchase product”, and describes from the standpoint of the user each step in the process of making the purchase.

Each use case includes three main elements:

  • Actors. These are the users outside the system that interact with the system.

  • System. The system is described by functional requirements that define an intended behavior of the product.

  • Goals. The purposes of the interaction between the users and the system are outlined as goals.

There are two formats to represent use cases:

  • Use case specification structured in textual format

  • Use case diagram

A use case specification represents the sequence of events along with other information that relates to this use case. A typical use case specification template includes the following information:

  • Description

  • Pre- and Post- interaction condition

  • Basic interaction path

  • Alternative path

  • Exception path

A use case diagram doesn’t contain a lot of details. It shows a high-level overview of the relationships between actors, different use cases, and the system.

Software prototypes

Software prototype is an umbrella term for different forms of early-stage deliverables that are built to showcase how requirements must be implemented. Prototypes help bridge the vision gaps and let stakeholders and teams clarify complicated areas of products in development. Traditionally, prototypes represent how the solution will work and give examples of how users will interact with it to accomplish their tasks.

Prototypes can be cheap and fast visual representations of requirements (throwaway prototypes) or more complex ones (evolutionary prototypes). The latter can even become the early versions of the product that already have some pieces of the final code. Effectively, evolutionary prototypes may even turn into MVPs that we’ve described in a separate article.

General recommendations to documenting non-functional requirements

Before winding up, let’s discuss the key things to remember when setting and documenting the requirements for software quality.

Make them measurable and testable. To understand whether your system meets quality constraints, make sure to quantify your requirements. You have to specify the units of measurement, the methods that you are going to use, as well as success and failure levels.

Set requirements for system components rather than whole products. Consider which critical interfaces and systems need such requirements. If your users never interact with some part of your product (e.g. an admin panel) setting up performance limitations for these components may be useless or harmful, since your team will expend much more effort with no evident gain.

Link NFR with business objectives. The minute-long difference in system availability may not have a drastic impact on your sales numbers, but sometimes it can mean additional weeks of engineering. Try breaking down your business objectives into system requirements.

Consider third-party limitations. If a third-party API that you must use returns data slower than you want, there isn’t much you or your team can do about it.

Consider architectural limitations. Legacy systems can put constraints on quality. While refactoring legacy code is doable, sometimes the current architecture must be completely reworked to meet some of the requirements.

Look for existing standards and guides. It’s likely that many system quality recommendations have been made before. So, check iOS or Android app guidelines to suggest some requirements for your app.

Last updated

Was this helpful?