The result of a project is a product. A project is generally understood as being a process with the following main features:
Definition according to [Stahlknecht2002]:
Organizational theory defines a system as “a set of elements that are in a working relationship”, i.e. a set of elements working together on a common task and therefore having an impact on each other.
A process describes the part of a system which transforms the inputs into outputs.
Processes represent the functions of the system that affect the data flowing into the system. A process consumes the input data, processes these data and passes on the result of processing in the form of output data. Processes can be refined, i.e. described by a corresponding data flow diagram.
This definition describes the term Stakeholder in the context of requirements management.
Definition according to [RobRob2006]:
“A Stakeholder is a person or an organization that has a potential interest in the future system and, as a general rule, sets requirements on the system. One person can represent the interests of many people or organizations, i.e. assume multiple roles”.
Requirements describe the user needs for a system and also the features that are defined by the framework conditions, e.g. statutory regulations.
According to [Pohl2007], the term “Requirement” is defined as follows:
There are three distinct types of requirements:
A functional requirement defines any of the systems or system components in order to provide function or in order to provide service. As a user requirement, a functional requirement can be described very generally. As part of a specification, it describes inputs and outputs as well as known exceptions.
A quality requirement defines a qualitative feature of the entire system, a system component or a function.
A framework requirement is an organizational or technological requirement that restricts the way in which a product is developed.
The breakdown into functional and non-functional requirements is commonly found in literature. According to Pohl, the breakdown into the three groups mentioned above is used because the non-functional requirements either turn out to be under-specified functional requirements or quality requirements. Thus, these are again assigned to functional requirements or quality requirements.
Requirements analysis is an activity or a part in a project.
In requirements analysis, the requirements for a system or a component are analyzed and recorded.
Requirements analysis can be implemented as an independent phase in a project; therefore all relevant requirements for the project are specified in detail at the beginning of a subsequent phase. Another possibility is to carry out the requirements analysis phase incrementally, parallel to the other phases.
The advantages as well as the disadvantages of each of these types of implementation are explained in more detail in the section Dealing with Requirements.
Any management, adjustments to and handling of requirements in the context of this book are defined as “requirements management”.
The Work Breakdown Structure (WBS) breaks the project down into organized work packages. These are arranged hierarchically and are necessary to achieve the project objectives. The WBS organizes and defines the entire scope of the project. The WBS subdivides the component parts of the project into smaller, better organized work packages. The deeper the entries in the WBS hierarchy are, the more detailed they are described. The entries at the lowest level are referred to as work packages and can be planned, estimated, monitored and controlled precisely.