Scribd
Upload
7 views12 pages

Requirements Engineering

Requirements engineering is a critical software engineering process that starts with stakeholder communication and continues through modeling, aiming to bridge to design and construction. It involves identifying stakeholders, recognizing multiple viewpoints, and fostering collaboration to resolve conflicts in requirements. Techniques such as priority points voting and traceability matrices are used to prioritize requirements and document their relationships with other engineering work products.

Uploaded by

charusps46
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
7 views12 pages

Requirements Engineering

Requirements engineering is a critical software engineering process that starts with stakeholder communication and continues through modeling, aiming to bridge to design and construction. It involves identifying stakeholders, recognizing multiple viewpoints, and fostering collaboration to resolve conflicts in requirements. Techniques such as priority points voting and traceability matrices are used to prioritize requirements and document their relationships with other engineering work products.

Uploaded by

charusps46
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

REQUIREMENTS ENGINEERING

tasks and techniques


• major software engineering action that begins during
the communication activity and continues into the
modeling activity

• builds a bridge to design and construction

• begins at the feet of the project stakeholders


• broader system
ESTABLISHING THE GROUNDWORK

• Identifying Stakeholders
• Sommerville and Sawyer [Som97] define a
stakeholder as “anyone who benefits in a direct or
indirect way from the system which is being
developed.”

• Ex: business operations managers, product managers,


marketing people, internal and external customers, end
users, consultants, product engineers, software
engineers, support and maintenance engineers,
Recognizing Multiple Viewpoints
• marketing group is interested in functions and features that will
excite the potential market, making the new system easy to sell.
Business managers are interested in a feature set that can be built
within budget and that will be ready to meet defined market
windows.
• End users may want features that are familiar to them and that
are easy to learn and use.
• Software engineers may be concerned with functions that are
invisible to nontechnical stakeholders but that enable an
infrastructure that supports more marketable functions and features.
• Support engineers may focus on the maintainability of the
software.
Working toward Collaboration
• The job of a requirements engineer is to identify areas
of commonality (i.e., requirements on which all
stakeholders agree) and areas of conflict or
inconsistency (i.e., requirements that are desired by
one stakeholder but conflict with the needs of another
stakeholder).

• It is, of course, the latter category that presents a


challenge.
Using “Priority Points”
• “voting” scheme
• Points spent cannot be reused.

• Once a stakeholder’s priority points are exhausted, no


further action on requirements can be taken by that
person.

• Overall points spent on each requirement by all


stakeholders provide an indication of the overall
importance of each requirement.
• Collaboration does not necessarily mean that
requirements are defined by committee.

• In many cases, stakeholders collaborate by providing


their view of requirements, but a strong “project
champion” (e.g., a business manager or a senior
technologist) may make the final decision about which
requirements make the cut.
Asking the First Questions customer
and other stakeholders,
• Who is behind the request for this work?

• Who will use the solution?

• What will be the economic benefit of a successful


solution?

• Is there another source for the solution that you need?


better understanding of the problem and allows
the customer to voice his or her perceptions
about a solution:
• How would you characterize “good” output that would be
generated by a successful solution?

• • What problem(s) will this solution address?

• • Can you show me (or describe) the business


environment in which the solution will be used?

• • Will special performance issues or constraints affect the


way the solution is approached?
effectiveness of the communication
activity itself.
• Are you the right person to answer these questions?

• Are your answers “official”?

• • Are my questions relevant to the problem that you have?

• • Am I asking too many questions?

• • Can anyone else provide additional information?

• • Should I be asking you anything else?


Nonfunctional Requirements
• quality attribute, a performance attribute, a security
attribute, or a general constraint on a system.

• quality function deployment (QFD) unspoken


customer needs or goals into system requirements.
Traceability
• Traceability is a software engineering term that refers to
documented links between software engineering work
products (e.g., requirements and test cases).

• A traceability matrix allows a requirements engineer to


represent the relationship between requirements and
other software engineering work products

You might also like