An overview of requirement engineering
Every software project has requirements, i. e. Facebook needs a system that is on 24/7. Requirements need to be formulated before developing the system, app or any software.
The software development process follows as shown in this diagram:
At the core of requirement analysis (engineering) we have a set of iterations between requirements and design as in the figure.
The big picture is that we start with requirements of a general system and then make some architecture decisions which led us to define requirements over the selected architecture and decide other architecture decisions and so on.
The key is to understand that requirements and architecture are really interconnected and both of the are at the heart of every software, not in code (implementation) but in the minds of the architects.
Problems in Requirement Engineering
Most of the problems in requirements are social ones and have to be with the misconception and inability to express what we want, the problem is becomes more difficult when we find out that the client don’t even know what it wants, so here there is a kind of philosophical dilemma: if people doesn’t know what they want does that mean that software development is exclusive of software architects? Just stop and analyze yourself: what makes you spend too long on social media or what keeps you playing that video game, most of us don’t want that addiction to technology but it is there exploiting our obscure inner desires.
If you want to go more practical you can see the following list of problems:
- Hidden requirements
- Inconsistent requirements
- Terminology (my idea of fast is not the same as yours)
- Unclear responsibilities
- Communication
- Moving targets (today you want something tomorrow other thing)
- Technically unfeasible requirements
- Stakeholders don’t know (they are nor in the management neither in the technical side)
- Underspecified requirements
- Unclear, unmeasurable non-functional requirements
Similarity between mathematical models and requirement engineering
Scientist use a lot models to represent the world and study it, this models can be thought as an abstract representation of reality with some restrictions, there is always a purpose in making the model (a desire) usually it is to explain reality.
In software engineering, usually when gathering the requirements we have 2 things:
- Desires
- Restrictions
Both of them are important, for instance some client would like to have more access to some data of the user in a mobile app but at the same time it has some limitations imposed by the operating system of the device (iOS, Android, etc.), so there is always this trade-off between desires and restrictions and this resembles economics, where there are a limited amount of resources but unlimited amount of desires. How to overcome this problem? In requirements this is done through modelling considering the desires and constrains.
