software process requirements in software requirements:
Software requirements:
The requirements of a system are a description of the service that the Lord has provided
System and its operational constraints. These requirements reflect user needs for a system that helps solve a problem, such as controlling a device,
Ordering or searching for information. The process of identifying, analyzing, documenting, and testing these services and barriers is called requirements engineering (RE). In this chapter, I focus on myself and what kind of needs
To explain them. I introduced the requirements engineering process in Chapter 4
And I discuss the RE process in more detail in Chapter 7.
The need for the term is not consistently used in the software industry.
In some cases, the need is just a high-level, service summary
That the system should be provided or the system is interrupted. On the other extreme,
This is a detailed, regular definition of system function. Davis (Davis, 1993) explains
Why these differences exist:
If a company wants to contract a major software development project,
It should summarize its needs in a fairly concise manner without prejudice to the solution. Requirements must be written so that multiple contractors can bid
Contract, offer, possibly, different ways to meet the client's organization
Requirements Once the contract is signed, the contractor must write a system
A more detailed compliment for the client so that the client can understand and validate what the software will do. Both of these documents can be called the requirements document for the system.
Requirements are the result of some of the problems that arise during the engineering process
Failure to make a clear distinction between these different levels of clarity. I differentiate between them using the term user needs for a higher level of abstract meaning
A detailed description of system requirements and system requirements means what the system should do. User needs and system requirements can be explained as follows.
1. User needs are statements in the diagram in addition to the natural language
Services are expected from the system and under these constraints
Should work
2. System requirements determine system functions, services and operational
Obstacles in detail. The system requires documentation (sometimes a
Functional specification) should be exact. It should explain what it is
Be implemented. This system may be part of an agreement between the buyer and
Software developers.
Different levels of system description are useful because they convey information about the system to different types of readers. Figure 6.1 illustrates the difference between user and system requirements. This example from the library system
Shows how user needs can be met in a variety of system needs.
You can see from Figure 6.1 that the user needs to be more abstract, and
The system requirements should include a description of these services and functions
To be provided by the system to be developed.
SE8_C06.qxd 4/4/06 9:00 Page 118
••
You need to write different needs at different levels because different types
Readers use them in different ways. Figure 6.2 shows the types of readers for this
User and system requirements. Those who read user needs are not usually
How this system will be implemented and its administrators can be related to it
Not interested in the detailed features of the system. Readers of the system
The requirements need to know more clearly what the system will do because it
Related to how it will help business processes or because of it
Involved in the implementation of the system.
6.1 Functional and passive requirements
Software system requirements are often classified as functional requirements, non-essential requirements, or domain requirements.
1. Functional Requirements These are statements of services that the system needs
Provide, how the system should react to what kind of input and what kind of system
Behave in special circumstances. In some cases, even practical requirements can clearly state what the system should not do.
2. Passive Requirements These are interruptions to the services or tasks offered
These include time constraints, barriers to development through the system
Process and standards. Passive requirements often apply to systems in the same way
As a whole, they usually do not apply only to individual system features or services. User and
System requirements
Functional and passive distribution
Software system requirements often have to be adjusted to practical requirements, non-essential requirements or domain requirements.
1. Description of functional distribution services that do system coating
Provide, what kind of system should respond and what kind of system it is
It is important to behave in special circumstances. In some cases, even practical calendars can clearly define those who do not want to understand the system.
2. Unnecessary Requirements These are hindrances to the services or functions offered
There are time constraints in the system, there are obstacles in development
Process and quality. Passive requirements often apply to such systems
This does not usually apply only to individual system features or services.
 |
| software development process |
3. Domain Requirements These are the requirements that will come from the application
The domain of the system and which reflects the features and constraints of that domain.
They can be practical or passive needs
In fact, the difference between the two types of needs is not so obvious
As these simple definitions suggest. Consumer needs related to security, say,
This may be a passive requirement. However, when more is ready
In detail, this requirement may lead to other requirements that are clearly functional,
Such as the need to add user authentication features to the system.