Modern software engineering handout 7 design phase spec

In the previous blog (typical users), we talked about how to collect, analyze, and verify user requirements. Here we will talk about Spec-specification.

Specification, also known as spec, has two types:

A) functional spec, software function manual, mainly used to describe the external functions of the software and the interaction with users (the software is treated as a black box)

B) Technical spec, software technical manual, also called design doc, design document, mainly used to describe the internal design of the software (the software is treated as a transparent box)

Some people say that we advocate practice and code & fix is our motto. What do we do when writing so many words? The last time I came to a demand, I saw the drawing. It was very simple. Isn't it just a chimney? Dry!

Half Done. The user gave me a try!

I am wronged.

The drawing has been taken down. I used to dig a well!

Later, I had to force "restructuring" and insert the chimney into the ground...

After the joke is over, let's continue to talk about functional spec: Describe the functional, input, output, interface, and functional boundary issues of the software product from the user's perspective, functional efficiency issues (for users), internationalization, localization exceptions, and so on; not involving internal implementation details of the software

Who will write spec? PM of the project, or other personnel

Who will implement spec? Developer, UX/UI Designer

Who will verify spec? Quality Assurance personnel (QA)

How to Write spec? It is actually a clear description. The following is an exercise:

If you want to describe how to tie your shoelaces to an alien and write a spec (in English) for "tie your shoelaces", how do you write it?

First, we need to define related concepts.

-What is "shoe", "shoe laces", "tied shoe laces", and "untied shoe laces", shoelaces, shoelaces, and shoelaces?

-Benefit of this feature "Tie your shoe laces ". What are the benefits of fasten your shoelaces?

-The goal of the feature? What is the purpose of shoelaces?

-What does "success" look like? What is it like?

-Unambiguous steps to achieve from "untied" to "tied" to demonstrate the process of shoelaces.

This is the spec written by two students to tie the shoelaces: Example 1, Example 2.

Second, we should standardize some assumptions (assumptions). For example, are shoelaces already worn on shoes? What kind of shoes do we have to deal?

 

 

Third, to avoid some misunderstandings, the following is also technically "tied to the shoelaces", but is it "tied up? Is the final settlement successful? How many bows are needed?

Fourth, clarify some boundary conditions. Which of the following conditions are good shoelaces? This requires pm/dev/test to reach an agreement. How tight is your shoelaces? Can I drag my shoelaces to the ground?

 

 

Fifth, describe the mainstream user/software interaction steps.

Sixth, there are some good features and side effects. We need to clearly write these side effects.

For example, in many regions of the United States, the former incandescent lamp is replaced by an energy-saving Lamp (LED), but the LED bulb is less heated, and the snow on the lamp cannot be melted in the snow, resulting in traffic problems. The original spec should write this side effect (dangerous.

 

 

Some people say that our agile team prefers direct face-to-face communication and does not like document or anything. How good is it!

In fact, in most cases, it is very good to leave a text document. Compared with the subsequent waste, the time spent is really too much. See the following example:

When I was studying, the teaching director came in and told the class monitor to "help me find two people, I want to work on flowers". At the same time, both hands made a flower-holding action on the chest and left. the class leader organized the class to vote for the class, made a class, made some big data, and finally unified his views, and selected the two most PL in the class. So two mm shyly went to the director and said, "Why are you? Where are boys? Okay, come with me for logistics. I want to move the flowers ..."

Face-to-face, direct communication is of course agile, but you still need to leave documents to clarify your needs.

 

In the development of large-scale software, we must be clear about the level and meaning of service quality. Otherwise, we will be confused. For example, how many floods can the Three Gorges Dam defend against?

Let's take a look at your understanding from 2003 to 2010:

People can not see the specific spec, can only say that the experts have a detailed explanation: http://news.163.com/10/0722/01/6C5MUM6R00014AED.html

There are only three tips for writing spec:

Practice, practice, and practice

 

What is the biggest enemy of spec? Boring. Most software companies do not like reading documents, let alone college students. Forcing college students to write tedious and unreadable documents is simply killing their interest in software engineering. How can I write a spec to make people read it?

1. Describes how a user uses software with real-life characters and stories (see typical users above)
2. Kiss-keep simple and direct description. UI-related parts can be directly used. You can also draw tables without writing long articles.
3. If it is a technical document, it is best to take the exampleCodeWrite, unit test is also written, letProgramEnsure the correctness of spec and allow readers to verify the correctness of spec.
4. Clarify the boundary conditions, and engineers of Science and Engineering thinking are excited when they see the brain here-they want to find out your spec flaws!

Another enemy of spec is time. The moment when SPEC was written, spec began to become obsolete. What should I do if my face is easy to get old and spec is especially bad?

1. Record the version revision time and owner-so you can find someone.
2. In spec, you should describe how to verify the description about the function. From spec description, you can know how to write unit tests. It is best to link the test cases.
3. Put spec, test cases, project tasks, and so on together (for example, on TFs.
4. Changes will certainly happen. Instead of intentionally ignoring this in spec, it is better to identify which parts are easy to change and make plans in advance. What kind of chain reaction will happen if changes are made.
5. When making any changes, make sure to refer to spec in advance and update spec later. team leaders should not make head shots without spec.

 

Is there a spec template?A lot of students may have such hopes. Once a document template or course PPT is obtained, most of the tasks will be successful.Blindly apply the most powerful template, which has major side effects on the project.Attention should be paid to PM. The preceding positive and negative examples are combined into a template:

1. What is the target of the spec?
2. What are spec users and typical scenarios?
3. What terms does spec use and what are their definitions?
4. How do users use software functions
5. What are various boundary conditions and how should software functions change?
1. These boundary conditions increase, the number of users changes, the upper limit and lower limit of input content, and the parameters of different countries/regions/cultures/languages/hardware/software versions/environments ....
6. What are the side effects of the function, and what are the explicit or invisible dependencies between other functions?
7. What is "Good"? What is this function tested and can be delivered?