Please enable JavaScript.
Coggle requires JavaScript to display documents.
Requirements Analysis, JOSÉ LUIS ROMO ARÁMBULA -- UP180163 -- …
Requirements Analysis
Requirements engineering
Inception
At project inception, you establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of preliminary communication.
Requirements engineering is an action that begins during the communication activity and continues into the modeling activity.
Elicitation
Elicitation also known as requirements gathering is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders.
Problems of scope.
The boundary of the system is weakly defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
Problems of understanding.
The customers are not completely sure of what is needed, don’t have a full understanding of the problem domain, have trouble communicating needs to the project engineer, omit information that is believed to be “obvious” .
Problems of volatility.
The requirements changes over time this could be either from the customer or from the project needs.
Elaboration
The information obtained from the customer during inception and elicitation is expanded and refined during elaboration.
Negotiation
It isn’t unusual for customers and users to ask for more than can be achieved, given limited business resources.
Specification
A standard template should be developed and used for a specification, arguing that this leads to requirements that are presented in a consistent and therefore more understandable manner.
Validation
Requirements validation examines the specification to ensure that all requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected.
Functional Requirements
The functional requirements for a project describe what the system should do.
What the product/service must do?
These are statements that the product should provide, how the product should react to particular inputs, and how the project should behave in particular situations.
Who reads the requirements document?
The readers need to know more precisely what the system will do because they are concerned with how it will support the business processes.
User Requirements
User requirements are statements of what services the system is expected to provide to system users and the constraints under which it must operate.
System Requirements
These are detailed descriptions of the project functions, services, and operational constraints.
The system requirements do not just specify the services or the features of the project that are required;
Non Functional Requirements
The non-functional requirements for a project describe How the system should do it.
Why failing to meet a non-functional requirement could be worst than a functional?
Failing to meet a non-functional requirement can mean that the whole product is unusable.
Implementation of non-functional requirements
Non-functional requirements may affect the overall architecture of a system rather than the individual components.
A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define new system services that are required.
Classification of non-functional requirements
Product requirements: these requirements specify or constrain the behavior of the product.
External requirements: this broad heading covers all requirements that are derived from factors external to the system and its development process.
Understanding Requirements
Identifying stakeholders
Stakeholder is anyone who has a direct interest in or benefits from the system that is to be developed.
The usual stakeholders in a project are: business operations managers, product managers, marketing people, internal and external customers, end users, consultants, product engineers, software engineers, support and maintenance engineers, and others.
Working toward collaboration
Put three stakeholders in a room and ask them what kind of product they want. You’re likely to get four or more different opinions.
Each of these opinions will contribute information to the requirements engineering process.
Recognizing multiple viewpoints
In many cases, stakeholders collaborate by providing their view of requirements, but a strong “project manager” may make the final decision about which requirements make the cut.
If five stakeholders are involved in a software project, you may have five different opinions about the proper set of requirements.
Understanding the requirements of a problem is among the most difficult tasks that face a project engineer.
JOSÉ LUIS ROMO ARÁMBULA -- UP180163 -- 18/02/2021