Analysis & Design
Outline
The Analysis & Design phase refers to a set of activities that we perform ahead of writing code. We want to examine our high-level technical requirements and make sure that we’ve addressed the business needs, user goals and technical requirements prior to implementation. We also want to determine the technical viability of our functional requirements, and any technical constraints that they will place on our design.
| Objective | Define non-functional requirements; Model high-level system (physical/logical models) |
|---|---|
| Activities | Determine technical impact and constraints, non-functional requirements; diagram high-level relationships |
| Duration | Varies (for our course, 2 weeks) |
| Outcome | Refined requirements that include technical detail; NFRs in GitLab; Architectural diagrams |
In the following sections, we will consider:
- Technical assessment - determine technical impact of functional requirements
- Software architecture - determine high level structure
- Software design - determine low-level structure and design
Technical Assessment
When we create functional requirements, we try and focus on determing our user’s needs without any consideration for the technical impact that they will have. We need to clearly separate functional from technical concerns so that we can collect information without prejudicing our requirements gathering process.
However, at some point, we need to determine the technical impact of each requirement:
- Will we be able to to implement this feature?
- What other technologies do we require for this to be feasible? (e.g. frameworks, libraries, toolkits).
- Does this put a constraint on our overall design? e.g. are we forced to use a particular OS, or deployment target?
- Is this feature risky; does it require significant novel research, or is it otherwise difficult to meet?
Each functional requirement from the requirements phase should be examined, and considered in this light. For many projects, the majority of requirements should be low-risk/feasible; introducing too many high-risk requirements could put the project itself at risk!
Your goal should be to amend the functional requirements with additional detail that will be useful in the Planning stage. Is this requirement risky? Add a statement to that effect and attempt to clarify the degree of risk! Does implementing one feature mean that you need to implement some other dependent functionality? Document that in the requirement as well! Your goal is to add technical detail to the existing requirements.
We should NOT attempt to disqualify or invalidate feature requests at this stage. Analysis & design is about gathering information and refining our understanding of our requirements. We do not make a determination of what to include or exlude until the Sprint planning stage.
Software Architecture & Design
Software Architecture and Design are related disciplines that are both concerned with the structure of a system. However, they represent different levels of abstraction: software architecture examines characteristics at a relatively high level of abstraction, but rarely goes down to the level of actual code; design is concerned with lower levels of abstraction – class composition and so on.
While a team might have a dedicated software architect, it’s very common for a senior developer or team lead to take on the “role” of the architect for the team. In other words, these don’t have to be different people, they simply represent different concerns that need to be addressed.
![Architect vs. Developer [Richards & Ford 2020]](assets/architect.png)
In the next two sections, we will address software architecture and design in greater detail. We cover architecture first, then move down into the details of software design.
As with many of the topics that we discuss, architecture & design are large and complex areas of study, and at best, we’re introducing and summarizing theses topics. Consider this a “highlight reel” of what we consider to be key considerations for analysis & design.
