UNDERSTANDING THE BUILD 1

Running head: UNDERSTANDING THE BUILD

Understanding the build.

David "Toby" Meyers

BSA/375 – Fundamentals of Business Systems Development

Donna Dulo -Instructor

University of Phoenix

July 29, 2009

 UNDERSTANDING THE BUILD 2

Abstract

This article analyzes the Requirements Engineering stage of Project Management. It

asserts that Requirements Engineering is the most important part of Project Management; it is the

understanding of what is to be built, empirically. It breaks Requirements Engineering down into

the three important parts. It considers the elicitation process as the assessment of client and

stakeholder interests. It considers analyzing the information from stakeholders and refining

project goals. It asserts that goals should communicate both the intent of the client and the

progress of the project; should reflect a timeline, make engineers, clients and stakeholders feel

like they are accomplishing something and show adherence to the requirements. It considers

communicating requirements in an understandable written form. It defines the different types of

Requirements and the syntax for communicating them.

 UNDERSTANDING THE BUILD 3

Understanding the build

The act of Requirements Engineering (RE) is having an understanding of what the build

is and to communicate that understanding in the written form to clients, stakeholders and those

who are going to build it. RE is one of the most important parts of Project Management; it

defines what is to be built according to specifications set by the client or stakeholders; it is the

understanding of what is to be built, empirically. The process of defining the requirements of the

build there are issues that must be considered before building. The communication of

requirements are essential to communicating the build. The first is the elicitation, of the design

specifications from the client and stakeholders. The second is analyzing the information from

stakeholders and refining project goals. The third is communicating requirements in an

understandable written form.

Elicitation Process

Elicitation is the act of gathering the basis for requirements from clients and stakeholders

and putting them together in a logical fashion. The elicitation, of the design specifications from

the client and stakeholders is the most important part of the build because it will define how

project managers and engineers define operations to be conducted. “Requirements engineering

denotes both the process of specifying requirements by studying stakeholder needs and the

process of systematically analyzing and refining those specifications,” (Hofmann & Lehner,

2001). “RE is concerned with interpreting and understanding stakeholder terminology, concepts,

viewpoints and goals,” (Easterbrook & Nuseibeh, 2000). In the Elicitation Process is often

necessary, “to cooperate with multiple stakeholders having different background, interests and

expectations; their concerns are generally partial and often conflicting partial. To move from

unstructured collections of sometimes inconsistent statements to a complete, structured set of

 UNDERSTANDING THE BUILD 4

consistent requirements; hidden, implicit needs and assumptions must be made explicit,”

(Lamsweerde 2008). This is because often stakeholders and clients interests are not the same;

while the client may want a project to be handled one way the project may be legally bound in

another or there may be opposition from community groups or even other businesses. What must

be considered in these circumstances is how the process must be handled to protect the interests

of all those involved in the project. After all the client may be the one who pays, but the

engineers who work on the project, the state, the community and the public at large is also

factors in any project. “Stakeholders are individuals and organizations that are actively involved

in a software project or whose interests the project affects” (Hofmann & Lehner, 2001).

Consideration of the intent of the client, the speculation of stakeholders, the ability to build such

a thing and adherence to local and federal law is part of Requirements Engineering and the key

to understanding the build.

Analyzing Requirements and Goal Refinement

Though some would say the analysis of requirements is part of the elicitation process.

“Writing requirements and testing are interrelated, much like the two sides of a Möbius strip,”

(Martin & Melnik, 2008). It’s necessary to sit down between elicitation and before writing the

communication, to consider the requirements and goals of the project; to make sure that

Requirements are consistent with the intention of the client, the speculation of stakeholders, the

ability to build such a thing and adherence to local and federal law.

Goals define the achievements and objectives of a project. Goals should communicate

both the intent of the client and the progress of the project. “The context in which RE takes place

is usually a human activity system, and the problem owners are people,” (Easterbrook &

Nuseibeh, 2000). Client and Stakeholders “goals may be constrained by a variety of factors
 UNDERSTANDING THE BUILD 5

outside their control,” (Easterbrook & Nuseibeh, 2000); “Goals denote the objectives a system

must meet,” (Easterbrook & Nuseibeh, 2000); Goals should reflect a timeline, make engineers,

clients and stakeholders feel like they are accomplishing something and show adherence to the

requirements as a fundamental part of the goals. Analysis of requirements and Goal Refinement

are essential parts of RE and should reflect the intentions of the client and stakeholder and

portray a timeline of project accomplishments.

Communicating Requirements

One of the most important parts of RE is communicating those requirements in an

understandable written form. Requirements are legally binding, in most cases and must be

understood by engineers, their staff, clients and stakeholders. “Linguistics is important because

RE is largely about communication,” (Easterbrook & Nuseibeh, 2000). The way things are said

can attribute to how a project flows and to complete a project on schedule. “That specifications

themselves need to be engineered, and RE represents a series of engineering decisions that lead

from recognition of a problem to be solved to a detailed specification of that problem,”

(Easterbrook & Nuseibeh, 2000). “The ability, not only to write requirements but also to do so in

a form that is readable and traceable by many, in order to manage their evolution over time,”

(Easterbrook & Nuseibeh, 2000).

The different types of requirements are speculative, tentative and definitive. Speculative

requirements are issues, normally associated as risks which may or may not affect a project but

are considered requirements or as goals as to prepare for those eventualities and to ensure that all

parties understand the risk associated with the process of the project. Tentative requirements are

things that are not implicitly required either by a certain time or are not crucial but should be

attempted as part of the complete project. Speculative and tentative requirements can be
 UNDERSTANDING THE BUILD 6

communicated as may, can, could and should. Definitive requirements are those actions that are

required to be done in a certain amount of time or are crucial for the completion of the project.

Definitive requirements are certainties and should be communicated as will, must and required.

Communications of requirements are essential to communicating the build so that clients,

shareholders and those who are going to build understand what it.
 UNDERSTANDING THE BUILD 7

Conclusion

The act of Requirements Engineering (RE) is having an understanding of what the build

is and to communicate that understanding in the written form to clients, stakeholders and those

who are going to build it. It should consider the intent of the client, the speculation of

stakeholders, the ability to build such a thing and adherence to local and federal law is part of

Requirements Engineering and the key to understanding the build. Goals should communicate

both the intent of the client and the progress of the project; should reflect a timeline, make

engineers, clients and stakeholders feel like they are accomplishing something and show

adherence to the requirements. Analysis of requirements and Goal Refinement are essential parts

of RE and should reflect the intentions of the client and stakeholder and portray a timeline of

project accomplishments. RE is communicating those requirements in an understandable written

form. The communications of requirements are essential to communicating what the build is. The

way requirements are communicated attributes to how a project flows and to complete a project

on schedule.
 UNDERSTANDING THE BUILD 8

References

Easterbrook & Nuseibeh (2000). Requirements Engineering: A Roadmap.

Retrieved July 27, 2009, from University of Toronto:

http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf.

Hofmann & Lehner (2001). Requirements Engineering as a Success Factor in

Software Projects. IEEE Software Magazine.

Retrieved July 28, 2009, from ACM Database:

http://www.acm.org.

IBM (2008). Requirements Engineering for Product Development from IBM.

Retrieved July 27, 2009, from IBM Solutions Database:

ftp://ftp.software.ibm.com/software/applications/plm/solutions/Requirements_Engineerin

g.pdf.

Lamsweerde (2008). Requirements Engineering: From Craft to Discipline.

Université catholique de Louvain: Department of Computing Science, Belgium.

Retrieved July 27, 2009, from ACM Database:

http://www.acm.org.

Martin & Melnik (2008). Tests and Requirements, Requirements and Tests: A Möbius Strip.

IEEE Software Magazine.

Retrieved July 28, 2009, from ACM Database:

http://www.acm.org.

Polga (2008).Requirements Engineering Explained.

Retrieved July 27, 2009, from Deversus Blog:

http://blog.deversus.com/requirements-engineering-explained.
 UNDERSTANDING THE BUILD 9

Simmons (2004). Requirements Triage: What Can We Learn from a

“Medical” Approach? IEEE Software Magazine.

Retrieved July 28, 2009, from ACM Database:

http://www.acm.org.

Sommerville (2005). Integrated Requirements Engineering: A Tutorial.

IEEE Software Magazine.

Retrieved July 28, 2009, from ACM Database:

http://www.acm.org.