Today we look at the Design stage of the SDLC
The inputs to the Design stage are requirements.
The purpose of Design is to formulate a solution or software specification to realise the system's requirements. The chosen design is elaborated in sufficient detail to to allow developers to implement it.
The scope of Design is:
Good design simplifies the job of the developer during the Implementation state of the SDLC and results in a system which meets the requirements of its users.
Poor design leads to costly re-work further into the SDLC and risks disengaging users or even losing customers.
The system designer/architect will be constrained by the non-functional requirements of the system such as:
They will also be affected by the quality of requirements and the availability of stakeholders for clarification of requirements.
Input design focusses on the interaction between the user and the system.
Output design focusses on the interaction between the system and an external actor (person or other system). It considers how data will be stored and processed.
We can identify inputs and outputs from the Use Case diagrams created as part of the Requirements Analysis stage.
User Interface (UI) design focusses on making the process of inputting data to the system "user-friendly".
Jakob Nielsen is one of the world's leading expert on UI design. Read his top 10 usability principles to find out what makes a usable UI.
Check out this website - does it conform to Jakob's heuristics? Which ones does it break?
This document shows the heuristics applied to Amazon's website.
Wireframes express the UI in a visual form and allow a basis for discussion before software is built.
Process Design focusses on how a requirement/Use Case will be realised via a set of software components. We refer to Design Patterns to find solutions to commonly occuring problems.
What Design Patterns are you aware of?
Architecture is defined by ISO/IEC 42010:211 as "The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution" (ISO 2011)
Let's look at some architectures from companies using Amazon Web Services (AWS) components. Listen closely to how non-functional requirements impact how the architecture is designed.
We can use a UML Component Diagram to represent architectural components, e.g. https://dzone.com/articles/solution-architecture-vs-software-architecture
Here is a very simplified architecture diagram created using a UML Component Diagrams for our SoFresh system.
Our non-functional requirements constrain our architecture and design, for example, how much hardware / cloud storage we may require, on which Cloud server the software will be deployed to.
Our process design at the moment is very high level, we can now drill into more detail by modelling the classes involved in the system and representing them using a UML Class diagram and then using a UML Sequence diagram to show the detailed interactions between components/classes.
The BCS documentation sometimes refers to sequence diagrams as interaction, collaboration or timing diagrams!
Next we might want to start thinking about our data structures. In object oriented (OO) programming, our data structures are mirrored in code and in the datastore. For example, our program might have an Order class that we interact with in our program, and each instance of an Order is also persisted as a row in a datastore.
We can use an Entity-Relationship Diagram (ERD) to model relationships between tables. It's like a class diagram but for databases!
Data design starts with the requirements. Once it is clear what needs to be persisted, often data is then normalised.
This is a technique used in data design to ensure data structures:
This webpage explain the process of normalisation through an example.
Another example of normalisation is how we store a one-to-many relationship in a relational database. For example, our Customers will have many Orders. To normalise that data structure we should store the Customer once and use their id in the Orders table to create that relationship.
Security and control design are the mechanisms we use to ensure the system has integrity and conforms to legislation such as GDPR. We introduce safeguards to protect data inputs and outputs as well as data at rest.
Examples include:
Add a UML Sequence diagram to your portfolio.
Do you use any Design Patterns? If so, mention them in your portfolio!
Find out what the architecture of your work application is. Does it run in the cloud? How does it protect against malicious inputs? What software & hardware components are deployed? How does it scale?