[en]01_Requirements
English | 中文
- Requirements analysis and design are the two most important parts in the software development process
- Writing code is in a sense the easiest
- And often the more you need to solve practical problems/long-term use/stable operation/maintainable software projects, the greater the proportion of demand analysis and design, it is no exaggeration to say that it can account for the entire software project from start to investment 80% of the time before use
- So Chapter 1 and Chapter 2 will teach you how to conduct requirements analysis and design. Let’s start with requirements analysis first and design in the next chapter
Now suppose you are a developer of a company, and the leader gives you a task, but the leader only said one sentence:
"Help me make a Todo command-line application with a recycle bin function"
Alright, it's time for you to get to work. You need to think from this sentence, and finally output a document describing the requirements of this application.
- What features should the app have?
main points:
- The process of thinking for yourself is the most important part of this chapter
- Try to forget what you saw in the preview, and reason about what functions this app should have, which is better and more convenient
- Don't be lazy, grab a pen and paper and think for at least 5 minutes
- Don't think about how to achieve it, just think about what to do
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Well, I'm assuming you've finished your thinking and have your answer.
Here are my thoughts, you can compare them with yours. This just represents my own thinking, does not mean that I am right.
- Add a todo
- Complete a todo
- Mark a completed todo as uncomplete
- Put a todo in the recycle bin
- Recover todo from a recycle bin
- Empty Recycle Bin
- Delete a todo
- Clear all todos
- List all uncompleted todos
- List all completed todos
- List all recycle bin todos
- List all todos
Because I can't easily communicate ideas with readers, even if I can, I can't take care of the different ideas of different readers, so I will continue the following content according to my own ideas, but remember that you still need to think for yourself.
For each function above, what should the interface(not program interface, but user interface) look like? (Strictly speaking, interface design should belong to the design stage, but I feel that it is very helpful to draw pictures when sorting out requirements)
Main points:
- Nothing can be done overnight, good articles are all modified
- Start with an initial idea and then build on it
Again, think for yourself, and draw your thoughts on paper before looking down.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- We start by adding a todo
- I added a todo, now what? It seems to be short of something, I think all the todos should be listed after adding a todo
- Eh? Are these todos completed or not?
- Looks better, next is to complete a todo
- What am I supposed to accomplish? It seems that I should list all the uncompleted todos first, so that I can judge which one to complete
- so let's first draw how to list all uncompleted todos
- Looks good, then we can choose which todo to complete
- Wait, do we have to type a full sentence to finish it?
- We seem to be giving todos a code name, so we modify the interface that lists uncompleted todos
- Now we can choose which todo to complete through a code (don't care about how to choose, how to set parameters, this is a matter of the design stage)
- Remember when we added a todo screen?
- After we add it, we should also display the code name of the added todo
- At the same time, we don't need to list all the todos after the addition is completed, users generally only care about uncompleted items
- Maybe we want to know when an uncompleted todo was created
- Maybe we want to know when a completed todo is completed
- Maybe we want to know when a todo in a recycle bin was thrown into it
- Maybe regardless of whether a todo is completed or uncompleted, I can throw it into the recycle bin, or delete it directly
- There should be a clear distinction between completed and uncompleted todos
- The todo after being thrown into the recycle bin should be marked
- etc
My final interface design is like this (don’t care about the user’s input, only care about the output interface)
Again, think for yourself, and write your thoughts down on paper before you read on.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Add a todo
- Record time when created
- Each todo should have a unique identifier (don't care how it is generated, when to start, etc., this is a matter of the design stage)
- The todo text should be able to include common special characters, such as
,,#,$etc. - The todo text can be multiline
- The text of todo should have a maximum length definition, this depends on your preference
- ...you can add more
- Complete a todo
- Record time
- Completing a todo should be idempotent, that is, the user completing a completed todo should be exactly the same as completing an uncompleted todo
- The user selects a todo that does not exist and should have corresponding error handling
- Mark a completed todo as uncomplete
- When the state changes, the completion time should be cleared
- Also idempotent
- Selecting a todo that doesn't exist should have error handling
- Put a todo in the recycle bin
- Time recording
- Idempotent
- Error handling
- Should remain constant whether its done or not
- Restore todo from a recycle bin
- Time to be thrown in the recycle bin should be cleared
- Idempotent
- Error handling
- Should remain constant whether its done or not
- Empty Recycle Bin
- Data records are physically deleted, i.e. unrecoverable
- Destroy a todo
- Data records are physically deleted, i.e. unrecoverable
- Error handling
- Clear all todos
- Data records are physically deleted, i.e. unrecoverable
- List all uncompleted todos
- Should not include todos placed in the recycle bin
- List all completed todos
- Should not include todos placed in the recycle bin
- List all recycle bin todos
- List all todos
Main points:
- Use unambiguous, precise language without ambiguous vocabulary
- Use
definitionreasoningproofwhat in one case and what in another - Without
I feelshouldseemobviously
This step is left as an exercise for the reader, after all, the hardest part is done, and the rest is just some writing work.
But don't skip it lightly, remember, Learning by doing, you can still learn a lot from it, otherwise you will gain nothing.
Note: Some very detailed requirements listed here will not be implemented in the tutorial, such as the length limit of todo, etc.
- You did it, you thought out a whole set of solutions from a word from the boss, it's amazing!
- It is not an exaggeration to say that requirements analysis is the most important step in the software development process.
- Every real problem-solving/stable/reliable/maintainable software project needs a clear goal.
- This goal is achieved by reducing the things to be done to a controllable/accurate/measurable range by means of requirements analysis.
- The output of requirements analysis is
requirements document, which is used as a guide for subsequent design and development.