As a Solution Designer, the first thing to look at is the system’s goals. When talking about goals, we are talking about the effect the system will have on the organisation.
This effect can be almost anything, but it should be clear how this will affect the organisation’s bottom line.
We should be fully aware of the system’s goals because, as Solution Designers, we must always think about the big picture.
To understand the big picture, we need to ask these questions:
- What is the environment that the system is going to be operating in?
- What are the main tasks the system is going to tackle?
Usually, the client/stakeholders should tell you what the system’s goals are, but it is not always the case.
Now it’s important to note we are not talking here about what the system should do. These are not goals. These are requirements, and it’s important to distinguish one from the other.
- Goals are NOT requirements. NOT what the system should do.
- Goals describe the effect on the organisation.
|System||Mobile Deposit Origination|
|Goal(s)||– Seamless onboarding experience for Mobile Origination.|
The goal is to seamless onboarding experience for Mobile Origination, thus attracting millennial mindset customers.
This, of course, will help the company build a better process, thus growing the revenue to.
Every software is based on some kind of requirements, some sort of user needs to accomplish something, and the software helps him achieve that.
For example, the requirement can be, I want to apply filters on my photos, or I need to communicate with my friends easily, or even I need to be able to tune my audio recording.
The requirement is whatever it is that the user needs.
These are the requirements. Of course, requirements are never left at such a high level during the development cycle. They become more detailed so the developers will have a clear idea of what they need to develop.