Systems & Requirements Engineering

regularly interacting or interdependent group of items that form a unified whole
homogeneous entity that exhibits pre-defined behavior and which is composed of heterogeneous parts that do not individually exhibit that behavior and which is an integrated configuration of components and/or subsystems

Systems that contain hardware, software, people and processes
Once the subsystems and components have been identified, system functions must be allocated to them. In systems engineering this is called functional allocation or functional analysis
There are a number of techniques that can be used to help make allocation tradeoff decisions.
Most of these techniques use a type of analysis called multi-criteria decision analysis (MCDA)

The word engineering is used as a way of emphasizing the use of systematic and repeatable techniques that help to ensure the completeness, correctness, consistency, and continued relevance of software requirements for a software product.

A requirement is a capability that must be delivered by the system, or a condition that the system must satisfy.
A functional requirement is something the system must do in other words, the behaviors the system must possess.
A functional requirement can have 5 moving parts inputs, outputs, statement of intended functionality, business rules, and possibly constraints.
A non-functional requirement is a condition that the system must comply with.

First, the requirements phase in a project can be a major source of defects that get introduced into the project.
Second, the requirements are used as input to many of the subsequent project work phases.
And, third, requirements errors can be costly and time-consuming to fix…and contribute significantly to a project’s rework costs.
Good requirements are correct, complete, testable, and unambiguous.

Analysts will identify key stakeholder groups, evaluate the system boundary, and elicit stakeholder needs to identify the project’s functional and non-functional requirements
Major deliverable work products produced in this activity typically include a Vision Document, a use case model or a functional requirements specification document if use cases are not being used, and a supplementary specification document.
The Vision Document specifies the stakeholders’ view of the product to be developed. It is written in terms of the stakeholders’ key goals/needs and desired features.
And it provides the basis for eliciting and specifying the more detailed product requirements.
Section 3 in this document is extremely important. It contains a description of product stakeholders and their needs. Note that there are two types of stakeholders: end user stakeholders and non-user stakeholders.
My first layer of stakeholders is what I call direct stakeholders. The next layer is the enterprise layer. And the third layer consists of entities outside the organization.

A use case describes a set of interactions between the product we are gathering requirements for, users of that product, and other systems the product will interact with.
Use cases are used to describe the functional requirements for a software product.

網站頁籤