Chapter two of the book is a small preview of the whole book, where the authors talk a bit about:
- engaging the stakeholders
- defining the problem
- what the system is
- what the system does
- the code
Stakeholders
The stakeholders are all the people and systems that care that this system even exists, what it does, or how it does it (pg. 28). This means anyone from developers to end-users, including business people, customers, designers, salesman, marketing, etc.
Nevertheless, not all stakeholders are relevant all the time in every context. To better know what the relevant stakeholders are in each context, and therefore in each meeting, we separate the system in two contexts and the relevant stakeholders:
- What the system IS:
The platform, the architecture, the product. In this context, the most relevant stakeholders are domain experts, system architects, and business people. - What the system DOES:
The functionality provided to the end-user. In this context, the main stakeholders are the end-users, the UI designers and the UX designers.
From all these stakeholders, however, the most important one is the end-user. The end-user mental model of the system is what is needed and therefore is what we should strive to reflect in the application.
Defining the problem
Before anything else, we need to define what it is that we need to create. Only after that, we can come up with a plan.
So the idea is that we get all the stakeholders together and convey a short description of the problem definition that everyone can agree upon. Defining the current state and the desired state is a great way to do this.
For some reasons, along the way, we might end up deviating from the plan, or the problem might change. Therefore we must revisit the problem definition often, to make sure that we are still on the right track and still solving a current problem.
What the system IS
The design of a system form is what a system is. The form is the most important factor for long-term system health. It must provide a firm foundation for the end-user functionality and also for the changes that will be needed in the future but can not be anticipated.
It’s interesting to note that the authors distinguish “form” from “structure” in a different way that I would. For the authors, “form” can be compared to a skeleton while the structure would be the meat that provides for the functionality. So they define “structure” as the actual code of an application.
Architecture focuses mostly in creating the form of a system:
- Capture the stakeholders’ perspectives that affect design;
- Embrace and prepare for change, to reduce the cost of solving problems;
- Create a shared vision across the team and stakeholders;
- Create mechanisms to smooth and fasten the decision-making process.
The architecture deliverables are:
- Class interfaces as source code contracts;
- Boilerplate code;
- Ubiquitous language;
- Minimal necessary documentation;
- Rule set of procedures, like coding standards.
With the architecture in place, we have a solid ground where to stand and respond to change.
Good form up front reduces cost in the long term.
Pg. 32
What the system does
The system should do what the end-user needs it to do. We need to capture the end-user mental model of the system, what he needs the system to do, how he envisions the system, how he dreams the system.
The way to capture this mental model is through the specification of use cases. Use cases define the various actions the end-user can do with the system, and are a valuable tool to elicit, explore, refine and capture the end-user vision of the system, but also to organise requirements, dependencies and priorities.
In this context, the deliverables can be:
- Screen designs;
- Domain specifications;
- Use case definitions.
Designing and coding
This is when we do the development of the product. At this point we:
- Extract actors and algorithms from the given use cases;
- Write system tests;
- Adjust the initial class interfaces;
- Translate the use cases into code;
- Run the tests against the written code.
@hgraca 