Previous
¶ Requirements Modelling
¶ What it is
The work of requirements modelling is to describe the system according to the system requirements in the form of text, graphics, tables, and formulas and provide a method to explain the structure or behaviour of the system in detail.
¶ Why it is useful
Requirements modelling is the most critical work of software modelling. The requirements model describes the external characteristics of the software, including the functions and performance that the software can provide to users. The analysis, design, and test models are all based on the requirements model. It is the basis of system design and implementation and improves the efficiency and quality of system development.
¶ When to use it
Before the production planning, during the research and business analysis phase.
Here are more readings on common ways of modelling.
- Scenario-based model: Scenario-based means to think and analyse from the perspective of the user end. User journeys and scenarios are the basis for analysis.
- Class-based model: Things that have similar attributes and common behaviours are grouped as a class. This kind of model depicts how classes relate or interact with other classes, with the attributes and behaviours defined for each class.
- Flow-oriented model: Digital products are based on a set of data processing that naturally forms the info flows in the system. Flow-oriented elements help the designers and developers to understand the expected input, processing, and output.
- Behavioural model: As a common tool for system analysis, behavioural models describe the dynamic behaviour of objects over time by establishing the life cycle model of class objects.
Scenario-based model
Scenario-based means to think and analyse from the perspective of the user end. User journeys and scenarios are the basis for analysis.
Steps to create a scenario-based model:
- Identify all the personas first
- List all the scenarios of each persona
- Abstract the systems or modules the user scenarios is going to interact with
- Link the persona and the activities with the system
Class-based model
Things with similar attributes and common behaviours are grouped as a class. This model depicts how classes relate or interact with other courses, with the attributes and behaviours defined for each class.
Steps to create a class-based model:
- Understand the system requirements
- Abstract the classes based on objects the system needs
- List the common attributes of each class
- Think about the relation between attributes and system, and how the user activities interact with the attributes, and how these classes interact with other classes
- Review the elements: class name, attributes, methods
Flow-oriented model
Digital products are based on data processing that naturally forms the Information flows in the system. Flow-oriented elements help the designers and developers to understand the expected input, processing, and output.
Steps to create a flow-oriented model:
- Sort out all the data in the system
- Understand the operation that processes the data
- Identify the states and variants of data and the relation between them
- Mark the data before and data after so as to identify the flow direction
- Use arrows to link where the data comes from and where it goes
Behavioural model
Behavioural models describe the dynamic behaviour of objects over time by establishing the life cycle model of class objects. State diagrams are often used to show the state machine (i.e. the state sequence of a specified object), the events and conditions that transit the object into these states, and the operations when the states are reached.
Steps to create a behavioural model:
- Access all the use cases to fully understand the sequence and interaction within the system
- Identify the activity and understand the relation between the specific activities
- Sort out the sequence for each use case
- Create a state diagram for the system based on the sequence
- Review the accuracy and consistency
¶ The output of Requirements Modeling
There is a wide variety of the output of the requirements modelling, depending on the complexity of the project and the audience that would consume the information, the team could decide in what form the requirement should be presented.
- Use Case Diagram: This tool is good at showing the product business logic together with the environment where the product would be deployed and used, the key system users and data flow could also be included.
- Product Concept: Product concept usually consists of test descriptions of key features and UI designs for the important product screens, it’s very useful when there are multiple product ideas and you need to compare or prioritise them.
- Product Prototype: A product prototype is a very simple quick demo of the product features, it’s usually used when the product is not very complicated, it could be a click dummy or a quick code demo, according to whether the design or tech is a more critical element
- Other Presentation Form: There are also a lot of other forms to present product requirements, such as product requirement documents, feature lists, user stories etc. All these tools could be used either alone or in combination.
¶ Use Case Diagram
¶ What it is
A use case diagram is a visual representation of the different tasks and functions that a product can perform. It can show the different scenarios in which the product will be used, the actions a user will take, and the interactions they will have with the product.
¶ Why it is useful
A use case diagram is visual, making it easier to understand and interpret. As such, it is helpful for clearly and effectively communicating a product's function, capabilities, and requirements to stakeholders such as designers, developers, and managers, which can lead to improved collaboration, idea generation, and design decisions.
¶ When to use it
Use case diagrams are typically created early in the design process and can be refined throughout the process as the design evolves. In the early stages of a project, during the requirements gathering and analysis phase, use case diagrams can be used to identify and document the different scenarios in which a product will be used, the actions that a user will take, and the interactions they will have with the product. This information is then used to create a clear understanding of the requirements for the development and to present to stakeholders what the product should do. When used in the later stages of the project, during the design phase, use case diagrams can be used as a way to validate the design of the product by simulating different use cases.
¶ How is it done
1. Understand the common elements for creating a use case diagram:
1. Systems - A system is a product you are developing, for example, a website or an application. A system is represented with a box/rectangle, also known as a system boundary. The system boundary defines the scope of the system.
2. Actors - An actor is anyone who acts on the system to achieve a goal. They can be a type of person, an organisation, or an external system (e.g., banking app customer, bank).
3. Use cases - Use cases are the scenarios in which the system will be used; they represent actions and functions within the system. They are placed within the system boundary because they occur within the system.
4. Relationships - Represented by lines, relationships depict interactions between and among the actors and use cases. Types of relationships:
- Association - Represents the interaction between an actor and a use case.
- Include - Represents a relationship and dependency between a Base use case and an Included use case. A Base use case requires an Included use case to be complete. E.g., log in (Base use case), verify a password (Included use case).
- Extend - Involves a Base use case, and an Extend use case. When a Base use case is performed, the Extend use case will only happen under certain conditions. E.g., Log in (Base use case), display login error (Extend use case).
- Generalisation - Represents a relationship between a Parent use case/actor and a Child use case/actor. E.g., Make payment (Parent use case), pay from savings/checking account (Child use case).
2. Identify the actors and use cases. An excellent way to identify use cases is to think about what the actors need from the system.
3. Using the four elements above, create a use case diagram with the identified actors and use cases.
¶ Do's & Don't
Do's
- Use simple shapes to represent actors and use cases
- Clearly define the relationship between the actors and use cases (i.e., include, extend, generalisation)
- Make sure the labels for uses cases are straightforward and meaningful (e.g., “print invoice” is preferable to “print”)
Don't
- Don’t create a too complex diagram; the main point of a use case diagram is to effectively communicate a product's function, capabilities, and requirements to various stakeholders
¶ Tools needed
- Miro
- Lucid Chart
- Other similar diagram creation online tools
¶ Example
¶ Product Concept
¶ What it is
The product concept comprises simple screens designed to show the product concept to stakeholders or potential end users. It offers the core user interfaces and features which help the audience understand the usage of the product.
¶ Why it is useful
When the concepts are complicated and challenging to explain with simple words, an image is worth a thousand words to help. Design screens are fast to create compared with click-dummies and even working applications. It saves cost but can efficiently improve communication during concept validation.
¶ When to use it
During requirement modelling, elicitation, validation, and early stages of design.
Before design production starts, concepts serve as experiments to see if the design is what the end users need.
¶ How is it done
- Review the MVP Definition, Product Vision, and BRD.
- Write down the key features and value proposition you need to get across - where are the highest value and the highest layer of complexity?
- Gather the product team to start scribbling ideas for those key leverage features and discuss and iterate to see what solutions you can come up with.
- The design team visualises the solution to share with stakeholders early and get their inputs as needed, based on a tangible visualisation they can comprehend more easily.
¶ Do's & Don't
Do's
- Focus on the key features that need elaboration
- Reduce complexity through intelligent visualisation
- Limit the time and effort invested here
Don't
- Don’t try to build out every feature or mock-up of too many areas. Focus on the key aspects
¶ Tools needed
¶ Example
Example 01
Digitalised shift log to track opertional records
A to-do-list to manage daily tasks
Example 02 Manager Checks E-Shop Overall Project Progress and Detailed Info
2.1 View Project Progress in Office
2.2 Auto-Generate Reports
2.3 Project Overview Displaying in E-shop
Scenario 2.1 E-Shop Manager Discuss Project Progress with Supervisor
Scenario 2.2 E-Shop Project Overview Displaying on TV
¶ Product Prototype
¶ What it is
A product prototype is an interactive design with logic links between screens, which makes the user feel like it is an application. Another name for it is click-dummy. The users can click on it and get feedback afterwards. In the case that the tech is the key element, it could also be a quick code demo with a very simple UI to prove the core functions.
¶ Why it is useful
Like product concept screens, a product prototype saves team efforts to develop a working application. Moreover, it creates almost the same user experience for the users, making them deeply understand the product and its features. This way, the product team can quickly and accurately get user feedback.
¶ When to use it
When words and images cannot explain the ideas to realise a product vision or the user operations are complex with sequencing logic, it’s better to create product prototypes for stakeholders to dive into the features in consideration deeply.
¶ How is it done
- Select a key user flow you want to test and get feedback on. Write out a storyline and discuss the flow with the team.
- Wireframe the flow and iterate with the team until everyone agrees on the solution route.
- Visually design the screens along the flow and connect them in a click path that follows a clear logic to create a fluent click dummy that can be tested with users.
- Or build a quick demo of the core function with very simple UI and mockup data.
¶ Do's & Don't
Do's
- Select a full flow that forms a story.
- Insert relevant data points into the storyline to make it feel more natural.
- Lay it out so a user can go about the task. It has to feel natural and logical.
Don't
- Don’t prototype low-priority features (like Settings or Reset Password); focus on critical features.
¶ Tools needed
¶ Example
