Software Requirement mode Read the five notes

This week I was learning the second chapter of the software requirements model------Requirements specification.

There is no single right way to block demand specifications so far, but the recurring theme in most systems is what we should be aware of and master. From the big aspect, the requirement specification can be divided into four parts, namely the introduction part, the context part, the functional domain part, the main non-functional requirement part four aspects, in which the function domain part defines the system actually to do the content.

The introduction section includes the system purpose, document purpose, requirement format, glossary, bibliography, and documentation history. This section is mainly about system specifications. It should be noted that the purpose of the system is the purpose of the system itself, not the purpose of the project, is to settle in the function; This part of the document is to consider identifying readers, disclaimers, simply describing the structure of the document, identifying other relevant requirements specifications, and this part mainly states that the system must meet the needs The requirements format helps the reader understand what is the right requirement, the requirements format includes the requirement identifier, the definition, the priority, the summary description four parts; In order to look more formally introduced a glossary, there are several terms in the glossary, each of which includes the term and its definition two parts The bibliography and document history are designed to better understand the system.

The most important part of the context is to determine the context diagram, that is, to determine the system boundary range, so we first need to find the components of the system, user roles, system boundaries, inter-system interface and other content. The main assumptions that affect the nature of the system should be highlighted in the main assumptions section or similar section where the requirements specification begins. Noting that the system is not obligated to implement functions called exclusions, this step greatly reduces the duration required by the system. Identify the core business entity as a key business entity, because the entire system is built around one or several core business entities, so we need to identify key business entities at the beginning of the system requirements. An infrastructure is the ability to support one or more required sets of requirements.

Next is the functional domain portion of the system core. Writing a section for each initiator is an important way of functional domains. Define and write the sections according to different functions, and arrange them according to the function importance. This helps to assign different energies of time and people to different functions of importance.

Finally, the main non-functional requirements section. The book describes the process of writing, which varies by system and relies heavily on the characteristics of the system.

The second chapter mainly explains the contents of the system specifications, and provides a template and a step for us to write the requirements, as well as the important content to be included.

Software Requirement mode Read the five notes