Requirements Engineering

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.