Collecting requirements for a software project - no bills
Development ... it is like a drug - the system is being written, they are writing, because the “rushing” is the same. And then, suddenly it turns out - you have to pay “alimony”. And any change in the system entails a mountain of errors. But even at the beginning of the last century, the great Kurt Godel foresaw this and strictly proved that even in arithmetic we are not smart enough to express all its laws without contradictions. And in programming, and even more so - we will begin to step on our feet and get confused. What, in general, is happening: then the laptop turns on and reboots at night, then mobile applications spill errors so that they start falling out of their pockets and scatter, scolding and squeaking, on the floor.
How do you like the now fashionable beta versions of everything and everything? Soon the planes will start coming out in alpha-beta versions, it seems.
But you can also program without errors, so that the soul is happy and the beer to drink with the client is not only pleasant, but also safe!
')
In this series of publications on various aspects of software development, I will try to form a minimalist set of values and rules, which, firstly, are placed in the head of the average person, and, secondly, usually allow ... to win with the least cost and time. Today we will speak frankly about the collection of requirements for a software system.
Theater, everywhere theater. But the software development industry will undoubtedly benefit if all participants in the process speak the truth, firstly, to themselves, and, secondly, nobody will support unsystematic emotions and service to Cthulhu around.
There is no need to go far for examples - open-source development models and their success (not necessarily non-commercial) convincingly show:
as well as the most fair communications, based on trust and respect for each other - lead a software solution, such as a website, to success.
The world is actively changing. Horizontal communications occur at the speed of light, and if we do not learn how to use this new weapon, we will definitely lose. But first, look a little around.
It's simple. Suffice it to recall the school course of geometry. The scientific understanding of the world in which we live is based on ... faith in "immutable truths" = axioms, for example, that "parallel lines do not intersect" or in the number of prime numbers in the range (although this is true, the theorem, but the dog works, but no one understands why).
It is impossible to prove an axiom, it remains only to believe that it always works. And we cannot yet fly to the horizon of the Black Hole events and check. And explain why the interaction between photons is transmitted much faster than the speed of light, too .
Numerous scientific theories use axioms for the inference of theorems, and so on and so thick books are born with a certain warranty period. As a result, and this is no longer funny, Fermat's Great Theorem was proven in the nineties so that only a handful of people with an excellent level of special education can crack the proof, able to shovel a few dozen pages of fine text with formulas under the microscope :-) That is why they continue the search for "real", simple and beautiful proof.
Even in a seemingly, well, what could be simpler, arithmetic, attempts were repeatedly made to bring axioms in order - but things are still there ...
Similarly, programming languages and technologies on which we are creating websites, mobile applications and information systems, in fact, also represent a set of axioms or points of reference, which also need to first "believe" and on which the foundation of technology is built, but it’s impossible to prove that they are correct (although, sometimes, you can still: try to write a website in C ++ and see how much time and money you will lose).
For example, in the world of Java / C # and other authoritative and solid, modern, strictly typed languages with static typing, you only need to take and “believe” once that the world consists of psychopaths prone to violence and loss of self-identification, and therefore a set of axioms does everything to protect the developer not only from colleagues, but also from himself (of course, I'm joking).
The result is software systems, which are created for a long time, from iron and concrete, which are then covered by hundreds of autotests, and as a result, it may turn out that the business requirements are outdated by the time construction is completed, nuclear weapons have been banned and a 100-meter-long wall bunker goes immediately to the museum. But often this perception of the world - works well, for example in the development of highly specialized systems or where the price of a mistake is very high (banks, etc.).
In the world of dynamic languages with strict / non-strict typing (PHP, JavaScript, Python, Ruby), the set of axioms is completely different from the word “absolutely”, another:
In the world of functional languages, such as Haskell / OCaml, you want to believe that:
As a result, instead of simple crutches “made, checked, decided and forgotten”, the real work begins in the workplace and searches for the “function of God” - it’s very interesting to express the website ... with a set of functions without variables, wow!
I, of course, exaggerate, but there is no smoke without fire. Although in some tasks this approach works just fine and has not come up with a better approach.
In the field of project management, the situation is even more covered with pseudoscience darkness. And the reason is well known: the obvious, lying on the surface, simple and concise solution to the forehead:
in reality, for some reason, does not work :-)
Experienced members of project teams are well aware that the customer often, trivially, does not know what he wants, because he is overwhelmed with emotions, and has copied tasks in mathematics at school, which led over time to a partial "atrophy of a part of the brain" responsible for the logically consistent expression of his thoughts. Having poetic opuses, lipstick drawings and guitar chord recordings, instead of technical requirements for the website, the experts, crying to avoid laughing from impotence, increase estimates of the amount of work by an order of magnitude, impose a tax for inadequacy, and so on.
In these conditions, the absence of strict logic and desire, excuse me, to use the head for its intended purpose, as on yeast, there are terrible unscientific abuses in the style of astrology / numerology / pranoynyadnosti and fortune telling on the coffee grounds.
Abuses are usually actively exploited by very self-confident people who are able to convince well, who have never held a “code” in their hands (yes, I’m talking about Agile which is not properly prepared).
They say that in some teams before the sprint even, especially ardent fans, force us, engineers, to, excuse me, urinotherapy :-) However, these “practices” themselves are often created by very experienced developers who, like no one else, can use them correctly.
I really like the analogy with nunchucks here - it seems to be a simple weapon, but only a few can use it correctly, and the majority are injured, forgive, you know what.
Sometimes they try to convince us of the interchangeability of engineers . It is known that in order to understand software technology well and deeply, you need to re-read quite a few books, listen to a dozen courses , solve several hundred tasks and take part in the top five software projects, of which at least one came to the finish line. Further - the experience begins, which in 5 years, at least, makes of the coder - Specialist.
Usually, constantly working on projects, the developer is fluent in one or two programming languages and related technologies. The success and professional growth of an engineer lies precisely in his narrow specialization, since besides the languages themselves, it is necessary to delve deep into the system libraries, which are often very numerous and have extensive documentation.
The problem is that now, for some reason, it is fashionable not to read books - but to google and write off, not including the brain, while at the same time mentally masturbating on social networks and smartphone notifications.
Finding a real specialist who systematically learns from the bottom up, slowly but surely, eliminating gaps in his own knowledge - it becomes more and more difficult. The market, unfortunately, is filled with "self-taught" with ... "spoiled hands."
First, do not despair and it is very important not to indulge in emotions. It is necessary to clearly understand that development is, first of all, rigorous mathematics (usually at the school level) and logic with metrics, in which it is necessary, using terver and intuition, to deal with priority risks and “drench” bosses even in infancy.
They used to play online games and it turned out well - go ahead, only instead of bosses you will have software projects, and instead of bugs - zerg!
It is always possible and necessary to soberly manage risks and, from experience, if done systemically and scientifically, a software project will either take off within a specified time, or it will quickly become clear why the rocket does not start and what is the problem, specifically.
In view of the above, it is recommended to begin as early as possible to adhere to the following values of the close-scientific-empirical approach, which closely intersect with the well-known anthem of common sense - “ python Zen ” and “ agile manifesto ”:
Having learned some secrets and peculiarities of the trends in software development, we will confidently move on - we will learn how to properly assemble system requirements.
Nothing funny - quite regular situation. And the customer in this context is a collective concept. First of all, try to assess the level of logical thinking and the ability to concentrate customer representatives. Who are you going to work with and who will help you? Possible options:
Another important point here is to build the most trusting relationship with the client, to show their openness and desire to help the customer to clearly express their thoughts. Often, some kind of training helps, where customer representatives are explained how to work with the following requirements collection tools:
Alarms that will indicate impending problems in the collection of requirements:
In the above clinical cases, again, well-developed on the basis of a finished boxed / cloud solution with ready-made documentation helps. Such an approach will, by orders of magnitude, reduce the risk of sudden changes in course by 180 degrees. But there are fewer guarantees.
In the case of an adequate approach on the part of the client, a desire to learn and understand you, a sincere desire to launch the project on time and develop further, the simultaneous use of several technological platforms helps well. Designing is no longer scary - you feel that the client shares the responsibility for collecting the requirements with you 100% and you can try to do him well. You insure each other and fight together with the complexity:
If 2-3 weeks, in a pinch, a month and a half, the feeling that you are participating in the play “we chat with a clever look and draw time and blame everything on someone” does not disappear, jerk the emergency tap, set fire to the train and shout loudly shout: “we go home, children! the presentation is over. "
Seriously, make an appointment with the client's management and insist on the inclusion of adequate staff in the project team who understand the details of how the business is organized and the engineers who are able to answer the strictly asked questions. Or quit - sometimes this is the most correct step: save your face and grow up as a specialist.
As a result, the process of collecting requirements can be considered successful and it makes sense to move on if, together with the customer, you were able to prepare the following artifacts within a couple of weeks:
If the above-mentioned artifacts for the specified period could not be collected, and there are only the fifth point covering papers like vague TK “lipstick”, the analysts do not cooperate with each other, experts in the subject area on the client side are not expected, problems are silenced and the pretentious atmosphere prevails and “Only good news” - collect things: most likely, they won't let you fly, the Moon exploration is postponed for an indefinite time and you get into a theatrical performance Do not overclock.
To achieve real success, it is very, very important to truly love software systems, devote to gathering requirements and design to the fullest, wish the missiles a speedy launch, drink beer with the customer, trust each other and constantly repeat the words of Edsger Dijkstra to themselves: “simplicity is a pledge reliability "!
With Coming all and sincerely wish good luck in the implementation of software projects.
How do you like the now fashionable beta versions of everything and everything? Soon the planes will start coming out in alpha-beta versions, it seems.
But you can also program without errors, so that the soul is happy and the beer to drink with the client is not only pleasant, but also safe!
')
In this series of publications on various aspects of software development, I will try to form a minimalist set of values and rules, which, firstly, are placed in the head of the average person, and, secondly, usually allow ... to win with the least cost and time. Today we will speak frankly about the collection of requirements for a software system.
Theater, everywhere theater. But the software development industry will undoubtedly benefit if all participants in the process speak the truth, firstly, to themselves, and, secondly, nobody will support unsystematic emotions and service to Cthulhu around.
There is no need to go far for examples - open-source development models and their success (not necessarily non-commercial) convincingly show:
- clarity, openness, courage
- discussion with the community and the client
- quick identification and problem solving
as well as the most fair communications, based on trust and respect for each other - lead a software solution, such as a website, to success.
The world is actively changing. Horizontal communications occur at the speed of light, and if we do not learn how to use this new weapon, we will definitely lose. But first, look a little around.
Where did the “holy wars” come from in programming?
It's simple. Suffice it to recall the school course of geometry. The scientific understanding of the world in which we live is based on ... faith in "immutable truths" = axioms, for example, that "parallel lines do not intersect" or in the number of prime numbers in the range (although this is true, the theorem, but the dog works, but no one understands why).
It is impossible to prove an axiom, it remains only to believe that it always works. And we cannot yet fly to the horizon of the Black Hole events and check. And explain why the interaction between photons is transmitted much faster than the speed of light, too .
Numerous scientific theories use axioms for the inference of theorems, and so on and so thick books are born with a certain warranty period. As a result, and this is no longer funny, Fermat's Great Theorem was proven in the nineties so that only a handful of people with an excellent level of special education can crack the proof, able to shovel a few dozen pages of fine text with formulas under the microscope :-) That is why they continue the search for "real", simple and beautiful proof.
Even in a seemingly, well, what could be simpler, arithmetic, attempts were repeatedly made to bring axioms in order - but things are still there ...
Similarly, programming languages and technologies on which we are creating websites, mobile applications and information systems, in fact, also represent a set of axioms or points of reference, which also need to first "believe" and on which the foundation of technology is built, but it’s impossible to prove that they are correct (although, sometimes, you can still: try to write a website in C ++ and see how much time and money you will lose).
For example, in the world of Java / C # and other authoritative and solid, modern, strictly typed languages with static typing, you only need to take and “believe” once that the world consists of psychopaths prone to violence and loss of self-identification, and therefore a set of axioms does everything to protect the developer not only from colleagues, but also from himself (of course, I'm joking).
The result is software systems, which are created for a long time, from iron and concrete, which are then covered by hundreds of autotests, and as a result, it may turn out that the business requirements are outdated by the time construction is completed, nuclear weapons have been banned and a 100-meter-long wall bunker goes immediately to the museum. But often this perception of the world - works well, for example in the development of highly specialized systems or where the price of a mistake is very high (banks, etc.).
In the world of dynamic languages with strict / non-strict typing (PHP, JavaScript, Python, Ruby), the set of axioms is completely different from the word “absolutely”, another:
- we are surrounded by smart people who write right and neatly right away
- persecution mania (changing the type of a variable below in listing, access to hidden members of a class by another developer with “malicious” intent, will definitely require deep code refactoring, etc.) - a disease that needs to be cured as soon as possible
- iron is getting cheaper, so you only need to compile the program with pieces and, if necessary,
- the more code, the more errors, so the code should be readable immediately, be clear, concise and sexy
In the world of functional languages, such as Haskell / OCaml, you want to believe that:
- any task can be expressed by function
- variables, cycles and mutability - leads to errors (this is in fact the case)
- programming - for chosen and inclined to analytical thinking
As a result, instead of simple crutches “made, checked, decided and forgotten”, the real work begins in the workplace and searches for the “function of God” - it’s very interesting to express the website ... with a set of functions without variables, wow!
I, of course, exaggerate, but there is no smoke without fire. Although in some tasks this approach works just fine and has not come up with a better approach.
"Crusades" in the management of software projects
In the field of project management, the situation is even more covered with pseudoscience darkness. And the reason is well known: the obvious, lying on the surface, simple and concise solution to the forehead:
- understand what the client wants
- attract specialists and estimate the scope of work
- write code
in reality, for some reason, does not work :-)
Experienced members of project teams are well aware that the customer often, trivially, does not know what he wants, because he is overwhelmed with emotions, and has copied tasks in mathematics at school, which led over time to a partial "atrophy of a part of the brain" responsible for the logically consistent expression of his thoughts. Having poetic opuses, lipstick drawings and guitar chord recordings, instead of technical requirements for the website, the experts, crying to avoid laughing from impotence, increase estimates of the amount of work by an order of magnitude, impose a tax for inadequacy, and so on.
In these conditions, the absence of strict logic and desire, excuse me, to use the head for its intended purpose, as on yeast, there are terrible unscientific abuses in the style of astrology / numerology / pranoynyadnosti and fortune telling on the coffee grounds.
Abuses are usually actively exploited by very self-confident people who are able to convince well, who have never held a “code” in their hands (yes, I’m talking about Agile which is not properly prepared).
They say that in some teams before the sprint even, especially ardent fans, force us, engineers, to, excuse me, urinotherapy :-) However, these “practices” themselves are often created by very experienced developers who, like no one else, can use them correctly.
I really like the analogy with nunchucks here - it seems to be a simple weapon, but only a few can use it correctly, and the majority are injured, forgive, you know what.
Another myth is interchangeability.
Sometimes they try to convince us of the interchangeability of engineers . It is known that in order to understand software technology well and deeply, you need to re-read quite a few books, listen to a dozen courses , solve several hundred tasks and take part in the top five software projects, of which at least one came to the finish line. Further - the experience begins, which in 5 years, at least, makes of the coder - Specialist.
Usually, constantly working on projects, the developer is fluent in one or two programming languages and related technologies. The success and professional growth of an engineer lies precisely in his narrow specialization, since besides the languages themselves, it is necessary to delve deep into the system libraries, which are often very numerous and have extensive documentation.
The problem is that now, for some reason, it is fashionable not to read books - but to google and write off, not including the brain, while at the same time mentally masturbating on social networks and smartphone notifications.
Finding a real specialist who systematically learns from the bottom up, slowly but surely, eliminating gaps in his own knowledge - it becomes more and more difficult. The market, unfortunately, is filled with "self-taught" with ... "spoiled hands."
What to do? Recommended survival values
First, do not despair and it is very important not to indulge in emotions. It is necessary to clearly understand that development is, first of all, rigorous mathematics (usually at the school level) and logic with metrics, in which it is necessary, using terver and intuition, to deal with priority risks and “drench” bosses even in infancy.
They used to play online games and it turned out well - go ahead, only instead of bosses you will have software projects, and instead of bugs - zerg!
It is always possible and necessary to soberly manage risks and, from experience, if done systemically and scientifically, a software project will either take off within a specified time, or it will quickly become clear why the rocket does not start and what is the problem, specifically.
In view of the above, it is recommended to begin as early as possible to adhere to the following values of the close-scientific-empirical approach, which closely intersect with the well-known anthem of common sense - “ python Zen ” and “ agile manifesto ”:
- Search for the simplest and clearest solution.
- The clearer, the more correct
- It became difficult - it means somewhere cant and you need to continue to look further
- Vysokoumiye - from uncertainty or difficult childhood
- The abilities of the human brain are limited, especially under the action of hormones, and in some periods too much
- From alcohol and smoking - we are intensely dumb
- We are inclined to quickly forget even what was well understood and even very recently
- Strive for maximum transparency and openness
- Respect each other
- Encourage the fastest possible ascent and discussion of problems in as wide a circle as possible - ideally at once in all
- Draw conclusions and do not step on a rake 3.14 times in a row :-)
Requirements for the collection of requirements
Having learned some secrets and peculiarities of the trends in software development, we will confidently move on - we will learn how to properly assemble system requirements.
Is the customer capable of thinking in principle?
Nothing funny - quite regular situation. And the customer in this context is a collective concept. First of all, try to assess the level of logical thinking and the ability to concentrate customer representatives. Who are you going to work with and who will help you? Possible options:
- Political party. We need to do, for example, a web project to a date because someone wants / promised something ... The requirements are blurred, no one knows the details, and who knew it would be long gone. The project was sawed by the team that went away and it’s almost impossible to understand what they sawed. On the walls - dried brains from, perhaps, a leading programmer's suicide. The code is bad and fragile, it smells so that it cuts eyes. Often in such a situation they are trying to find, excuse me, a “sacred sacrifice” to which it will be possible to dump the next six months and ... start looking for a new one. Feeling of fear, depresnyaka and suppression of the openness of the process with an admixture of blood on the lips. The probability of making a software decision in time, though small, is still there - if you re-do it on a ready-made framework with ready-made documentation. Usually the only way and nothing else.
- You communicate with representatives of the client and understand that it is sincerely difficult for people to consistently / formally express their own thoughts, which are confused after the third sentence, are repeated and walk in a circle. After 15 minutes of dialogue, headache complaints begin. You can hear the laughter, the atmosphere of a party, a selfie, life is a success ... But the desires, in general, are clear and sincere - you just need a little help to arrange them strictly. The probability of flying up here is usually higher than in claim 1, but again, it usually helps to use as much as possible ready, boxed solution with ready documentation and sample scenarios.
- The client is well aware of what he wants and tries to logically consistently express his own thoughts and desires. The analyst helps him in this, who is not confused, stating the thoughts of the management and passing them off as his own. The client’s team also has at least one expert in its subject area (funny, but this is quite a rare situation). In this case, the probability to help and solve the problem programmatically is very high. Here you can get involved in the design, joint discussion of the glossary, object models, data models, data flows, load testing scenarios. Most likely, you can collect the requirements and in a reasonable time.
Another important point here is to build the most trusting relationship with the client, to show their openness and desire to help the customer to clearly express their thoughts. Often, some kind of training helps, where customer representatives are explained how to work with the following requirements collection tools:
- Glossary in which general formulations are written
- A logical data model in which strict multiplicity relationships are introduced between the elements of the glossary (one to one, one to many, many to many)
- Roles and use chains that show who uses the system and how
Alarms that will indicate impending problems in the collection of requirements:
- customer representatives translate the arrows to each other and cannot connect two words, with a lot of emotions - it is recommended to escalate the problem as quickly as possible and go up a level - otherwise, as a sacred sacrifice, you will be presented with a bardak culture and retirement / dec. Working in such conditions on Agile is extremely dangerous, it is better to write strict TK and move in small steps.
- Representatives of the client respond in style: oh, my head hurts, and you are clever, a “programmer”, so understand. Here you need to find an expert in the subject area responsible for the answers on behalf of the customer and as soon as possible. Or see the paragraph above.
- they prefer not to talk about problems (unreadable code, lack of documentation for the main business processes), since money was spent, positions were received, premiums were voiced, and speaking risks could lead to an intensive cleaning of the staff (yet everyone “understands”, and then engineers roll a barrel) - it’s difficult to advise, act according to the actual weather
In the above clinical cases, again, well-developed on the basis of a finished boxed / cloud solution with ready-made documentation helps. Such an approach will, by orders of magnitude, reduce the risk of sudden changes in course by 180 degrees. But there are fewer guarantees.
In the case of an adequate approach on the part of the client, a desire to learn and understand you, a sincere desire to launch the project on time and develop further, the simultaneous use of several technological platforms helps well. Designing is no longer scary - you feel that the client shares the responsibility for collecting the requirements with you 100% and you can try to do him well. You insure each other and fight together with the complexity:
- php website with boxed framework
- predictive analytics in python
- mobile application either on a single platform that works everywhere, or we write for each device
Do not delay the time!
If 2-3 weeks, in a pinch, a month and a half, the feeling that you are participating in the play “we chat with a clever look and draw time and blame everything on someone” does not disappear, jerk the emergency tap, set fire to the train and shout loudly shout: “we go home, children! the presentation is over. "
Seriously, make an appointment with the client's management and insist on the inclusion of adequate staff in the project team who understand the details of how the business is organized and the engineers who are able to answer the strictly asked questions. Or quit - sometimes this is the most correct step: save your face and grow up as a specialist.
Check list
As a result, the process of collecting requirements can be considered successful and it makes sense to move on if, together with the customer, you were able to prepare the following artifacts within a couple of weeks:
- Glossary that lists 50-150 subject terms
- Logical data model with glossary terms
- Use Cases with Glossary Terms
- For complex algorithms - flowcharts or UML activity diagrams
- Interfaces of the software system, which do not logically contradict the above points
- You have decided on a set of axioms that describe your attitude to the world = have chosen a software technology. Many here, because of the love of creativity, are drawn to sado-masochism and the desire to reinvent bicycles - fight this desire. Decide on it: either the whole world is full of dirty tricks and psychopaths and we are making a bunker that can withstand a UFO attack, or the developers sincerely want to help you. The best technology and set of axioms: a developed framework or a ready-made boxed solution - the risks of not flying up will decrease by orders of magnitude (according to experience, 95% and more of projects take off)
- You missed the software system through the customer, yourself, through your brain and nowhere left muddy places or emotional slush. If such potentially rotten places are available (and this, as a rule, always happens), include them in the risk management plan and voice them at each project meeting. And expect that they will substitute you and will surely ask you how you missed it.
If the above-mentioned artifacts for the specified period could not be collected, and there are only the fifth point covering papers like vague TK “lipstick”, the analysts do not cooperate with each other, experts in the subject area on the client side are not expected, problems are silenced and the pretentious atmosphere prevails and “Only good news” - collect things: most likely, they won't let you fly, the Moon exploration is postponed for an indefinite time and you get into a theatrical performance Do not overclock.
To achieve real success, it is very, very important to truly love software systems, devote to gathering requirements and design to the fullest, wish the missiles a speedy launch, drink beer with the customer, trust each other and constantly repeat the words of Edsger Dijkstra to themselves: “simplicity is a pledge reliability "!
With Coming all and sincerely wish good luck in the implementation of software projects.
Source: https://habr.com/ru/post/432650/
All Articles