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

Revision 1, October 1, 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 the project build, empirically. It breaks Requirements Engineering down into

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 art of Requirements Engineering (RE) is having an understanding of the build

process. The act of RE is to communicate that procedure in written form to clients, stakeholders

and those who are going to build it. RE is the most important part of Project Management; it

defines what and how what the build process is according to specifications set by the client or

stakeholders. In the process of defining the build process, the requirements of the build there are

issues considered before building. Correct grammar and diction is 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 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 consistent requirements; hidden, implicit needs and
 UNDERSTANDING THE BUILD 4

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

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 is 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

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

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 be understood

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

about communication,” (Easterbrook & Nuseibeh, 2000). The way procedure and timeline is

communicated 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

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

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

requirements that while not implicitly required by a certain time or are not crucial for project

completion. The completion of tentative requirements attempted as part of the complete project,

which defines how successful abatement of post project risks or damages from hidden
 UNDERSTANDING THE BUILD 6

requirements. Speculative and tentative requirements are requirements that are conditional on

ability to complete them or not crucial elements of completion and communicated as can, may,

could and should. Definitive requirements are those actions required 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 the process of the build.

 UNDERSTANDING THE BUILD 7

Conclusion

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

process. The act of RE is to communicate that procedure in 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. The completion of tentative requirements attempted as part of the

complete project, defines how successful abatement of post project risks or damages from hidden

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 ways

requirements are articulated are essential to communicating the build so that clients, shareholders

and those who are going to build the project understand the process of the build.
 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 IEEE 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 IEE 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 IEEE Database:

http://www.acm.org.

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

IEEE Software Magazine.

Retrieved July 28, 2009, from IEEE Database:

http://www.acm.org.