Collecting requirements for a software project - no bills
Development ... it is like a drug - the system is being written, they are writing, because “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 do not have enough intelligence 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 apps spill errors so that they start falling out of their pockets and scatter, scolding and squeaking, on the floor.
And how do you like fashionable now 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 collecting 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, no one 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, for example, 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 around a little.
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 ... belief 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 still cannot fly to the horizon of the Black Hole events and check. And explain why interaction between photons is transmitted much faster than the speed of light, too .
Numerous scientific theories use axioms for the logical derivation 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 who can shovel a few dozen pages of fine text with formulas under a microscope can understand the evidence :-) 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 writing 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 identity, 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).
As a result, software systems are created, 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 by the end of construction business requirements are outdated, nuclear weapons were banned and a 100-meter-long 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 they did 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, it 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 math tasks in school - he wrote off, which led in time to partial “Atrophying a part of the brain” responsible for the logically consistent expression of their thoughts. Having poetic opuses, lipstick drawings and guitar chord recordings, instead of technical requirements for the website, the specialists, crying not to laugh at powerlessness, increase the 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 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 - like 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. Further - the experience begins, which in 5 years, at least, makes of the coder - the 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 in addition to 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 a terver and intuition, to deal with priority risks and "drench" bosses in infancy.
They used to play online games and it turned out well - go ahead, only you will have software projects instead of bosses, and zerg instead of bugs!
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, who, specifically, is the problem.
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 collect 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 express their thoughts clearly. 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 risks 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 against the complexity together:
If 2-3 weeks, at least a month and a half, do not get the feeling that you are participating in the play “we will chat with a clever look and pull time and blame everything on someone,” pull the stop-switch, set fire to the train and shout loudly shout: “we are going home, children! the presentation is over. "
Seriously, make an appointment with the client's management and insist on the inclusion of adequate staff on 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 start, drink beer with the customer, trust each other and constantly repeat themselves to themselvesEdsger Dijkstra : “simplicity is the key to reliability”!
With Coming all and sincerely I wish you good luck in the implementation of software projects.
And how do you like fashionable now 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 collecting 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, no one 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, for example, 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 around a little.
Where did the "sacred war" in programming come from?
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 ... belief 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 still cannot fly to the horizon of the Black Hole events and check. And explain why interaction between photons is transmitted much faster than the speed of light, too .
Numerous scientific theories use axioms for the logical derivation 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 who can shovel a few dozen pages of fine text with formulas under a microscope can understand the evidence :-) 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 writing 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 identity, 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).
As a result, software systems are created, 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 by the end of construction business requirements are outdated, nuclear weapons were banned and a 100-meter-long 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 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 they did 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 amount of work
- write code
in reality, for some reason, it 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 math tasks in school - he wrote off, which led in time to partial “Atrophying a part of the brain” responsible for the logically consistent expression of their thoughts. Having poetic opuses, lipstick drawings and guitar chord recordings, instead of technical requirements for the website, the specialists, crying not to laugh at powerlessness, increase the 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 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 - like 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. Further - the experience begins, which in 5 years, at least, makes of the coder - the 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 in addition to 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 a terver and intuition, to deal with priority risks and "drench" bosses in infancy.
They used to play online games and it turned out well - go ahead, only you will have software projects instead of bosses, and zerg instead of bugs!
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, who, specifically, is the problem.
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 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 collect 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 quit a long time ago. 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” on which it will be possible to dump the next six months and ... start looking for a new one. Feeling of fear, depresnyak 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 get confused after the third sentence, repeat 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 the most finished, boxed solution with ready documentation and sample scenarios.
- The client understands well 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 express their thoughts clearly. Often, some kind of training helps, where customer representatives are explained how to work with the following requirements collection tools:
- A 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 "arrows" at 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 cult 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 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 up of 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 risks 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 against the complexity together:
- 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, at least a month and a half, do not get the feeling that you are participating in the play “we will chat with a clever look and pull time and blame everything on someone,” pull the stop-switch, set fire to the train and shout loudly shout: “we are going home, children! the presentation is over. "
Seriously, make an appointment with the client's management and insist on the inclusion of adequate staff on 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 that 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. There are many, because of the love of creativity, drawn to sado-masochism and the desire to reinvent the bicycles - fight this desire. Decide on it: either the whole world is full of dirty tricks and psychopaths and we are doing a bunker that can withstand a UFO attack, or the developers sincerely want to help you. The best technology and a set of axioms: a developed framework or a ready-made boxed solution - the risks of not flying up will decrease by orders of magnitude (by 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 swelling 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 start, drink beer with the customer, trust each other and constantly repeat themselves to themselvesEdsger Dijkstra : “simplicity is the key to reliability”!
With Coming all and sincerely I wish you good luck in the implementation of software projects.