Print Email Download Reference This Send to Kindle Reddit This
submit to reddit

The Requirement Gathering Techniques Information Technology Essay

Requirement gathering is the first phase in the development of any software product. A comprehensive understanding of the client’s needs and listing out features of the proposed software product are the keys to success in this phase. This phase is very important for the development process as a weak foundation means that the product will potentially not have a place in the market. Essentially, there has to be sufficient demand and requirement by customers to form the basis as to why a software product should be created.

In this report, I will be touching on 4 different methods of requirement gathering techniques, namely interview, requirement workshops, brainstorming sessions and storyboards. As mentioned, the first step in requirement gathering is to understand the problems a new system is trying to resolve. And using the most appropriate methods of approach to understand and familiarize before building a system.

Interview

It is one of the primary techniques in which system analysts must be skilled in as the interviewing skills determines the types of information gathered and the quality and depth of the information.

Interviews can be conducted on different types of purposes for different goals.

Initial introduction

Familiarization or background

Fact gathering

Verification of information gathered elsewhere

Confirmation of information gathered from the interviewee

Follow-up, amplification and clarification

Who to Interview

the most senior manager,

his or her subordinates and junior managers, and

line workers, clerks, production people and sales staff.

Goals to achieve from an Interview

Gathering of information on the company

Gathering of information on the functionality

Gathering of information on the activities, process and workflow

Finding out the complications and constraints

Finding out the requirements and needs determination

Verify the previously gathered facts

Giving adequate information

Gather key points for further interviews

Bearing these goals in mind, the system analyst will have to formulate the appropriate questions prior to the interview, and to also document the information gathered.

Documentation is in fact very important and it serves to clarify understanding. It also provides the audit trail for the system analyst. It creates the records which can be referred to at a later date and serves as a tool for future work and decision making. Good documentation can avoid repetition of questions and there is the possibility of repeated reviews until adequate understanding is achieved. It can also allow other analysts to pick up where it was left off, should he or she be reassigned.

Requirement Workshops

Also known as the Joint Applications Design (JAD) and Joint Requirements Analysis (JRA), it is actually an extended facilitated workshop which involves stakeholders and system analysts to identify the needs or requirements in a joint effort.

Advantages

Promotes teamwork with the customer

Creates a design from the customer’s perspective

Produces relatively large amounts of information

Discrepancies are resolved immediately with the aid of a third party facilitator

Disadvantages

Requires significant amount of planning and scheduling effort.

Requires significant amount of stakeholders’ commitment of time and effort.

Requires trained, experienced and professional personnel for facilitation and recording.

Generic Process Steps

Planning & Definition

Establish the needs for the system

Select the team members

Defining the scope of the session

Preparation

Schedule the design sessions

Conduct orientation and training for design session participants

Prepare the materials, room, and software aid

Conduct the kickoff meeting

Design Sessions

Revision of the project scope, objectives and cost

Identify data, process and system requirements

Identify the different system interfaces

Developing prototypes

Assigning the facilitator to resolve all disputes and issues

Documenting and recording of the whole sessions

Finalization

Completion of the design documents

Signing off the design documents

Obtain the approval to proceed

Evaluation

How to make a Requirement Workshop Successful

Success requires management commitment

Participants must attend the entire session

Requires a trained facilitator

Having the right people in the session

All participants are equal

Preparation is more important than the session itself

Making an agenda and sticking to it

Using appropriate tools and techniques during the session

Keeping technical jargon to a minimal

Produce quality documentation and recordings of the session

Brainstorming Sessions

Brainstorming is perhaps the most commonly used tool for expressing thoughts and ideas. This requires that the stakeholders gather in the same room, and that the stakeholders have a common understanding of the issue for the upcoming project. With a common understanding, you can at least be certain that there will be constructive output.

Brainstorming sessions focus on quantity of ideas thus, cultivating an environment inducing everyone in the session to voice out. If some of the ideas voiced out in the session are not feasible or out of topic, never put them down. Instead, prepare the stakeholders before the session so their creativity will start before the session.

Brainstorming Sessions with several people having the same needs for the new application site in a room together enhance the experience as one creativity idea might strike another. This could be used where having a team that performs the same work with the application or at least familiar with each other’s usage of it. While brainstorming is not appropriate where you have a small group of stakeholders with disparate needs or geographically dispersed.

Brainstorming Process

Define and agree on objectives

Brainstorm ideas and suggestions based on an agreed time limit

Categorize, condense, combine and refine

Assess and analyze effects or results

Prioritize options and rank list as appropriate

Agree action and timescale.

Control and monitor follow-up.

Advantages

Does not require a highly qualified expert or highly paid consultant

Inexpensive

Very productive in generating ideas

Encourages creative and “out of the box” ideas

Provides an opportunity for widespread participation and involvement

Storyboards

Storyboarding is a means of capturing requirements in a graphical display rather than in text. It borrows from the entertainment industry where the technique was first used in cartoon production.

Using storyboards to capture requirements involves the recorder drawing on a screen or white board. The screen will contain all the information to be displayed as well as the input fields required to gather information. The storyboard is used in a workshop setting with a facilitator and recorder. The facilitator and recorder will start the session by creating a screen for the first major need to be expressed. This might be a log in screen, or some other screen capturing a fundamental function. The original screen may trigger subsequent screens to complete the function. For example, the first order entry screen may capture information common to every order and require subsequent screens to capture information that is unique to different types of orders, for example one screen each for a software order, a computer order, and an operating manual order. The storyboard will develop the screens as the group navigates through each function or requirement.

Since the storyboard can only capture a few states for each screen, it is important for the recorder to capture the different states each screen may have and the behavior of the screen upon different inputs (how errors are handled, how input information is verified, etc).

One advantage of storyboarding is its ability to define the screens that will be a key feature of the application, and get consensus in a group setting for each screen's look and feel. This method is appropriate where the application being developed is GUI based, or for web sites. It is also appropriate where the stakeholders being solicited are collocated so they can participate in the workshop. It will not be appropriate where the stakeholders are geographically dispersed, or the application being developed is not GUI based.

Conclusion

There isn’t a best method for requirement gathering as different scenarios will require different methodology. The ideal solution is a combination of different methods that will be beneficial in creating a system that serves and solves a problem. As planning is very important in all projects, combining the different methodologies will make use of the advantages of different techniques to cover all areas in requirement gathering. A survey can reach a large number of stakeholders or other sources of information and it requires very little time to get a substantial amount of focused data, followed by interviews which provide an opportunity to explore or clarify topics in more detail. The process is then completed with a brainstorming session where the one idea can spark off other ideas and it can create the co-operation between stakeholders. Using this method above also makes it very systematic in gathering information and making sure it covers all angles in a short span of time.

References for Task1

Introduction - http://www.faqs.org/docs/ldev/0130091154_25.htm

Interview - http://www.martymodell.com/pgsa2/pgsa07.html

A Professional's Guide to Systems Analysis, Second Edition Written by Martin E. Modell

JAD - Wood, Jane and Silver. Joint Application Development. John Wiley & Sons, 1995.

Brainstorming Summary - http://ezinearticles.com/?Requirements-Gathering---Choosing-the-Right-Tools&id=2439512 Author: Dave_Nielsen

Brainstorming Advantages - http://www.stsc.hill.af.mil/crosstalk/2002/04/young.html

Author: Dr. Ralph R. Young, Northrop Grumman Information Technology

Storyboard summary - http://ezinearticles.com/?Requirements-Gathering---Choosing-the-Right-Tools&id=2439512 Author: Dave_Nielsen

Task 2 Class Diagram

Task 3 Activity Diagram

Task 4

Introduction

The differences between the structured and object oriented approach is

Structured Approach is using SDLC Methodology and the focus is processed, the risk is high and the resusability is very low. It is suitable for well-defined projects with stable user requirements. While the object Oriented approach methodology is iterative and incremental, its focuses on objects and the risk is low. Reusability is also high for this approach and it is suitable for risky large projects with changing user requirements. Structured approach will consist of ERD (Entity-Relationship-Diagram) and DFD (Data-Flow-Diagram) while UML will consist of the Case diagrams and Class Diagrams.

Figure UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, UCDs can be used to show all of its available functionality. It is important to note, though, that UCDs are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed. There are a number of graphical examples in this FAQ; you might want to look over them to familiarize yourself with the look ofthem.

UCDs have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements.

You should use UCDs to represent the functionality of your system from a top-down perspective (that is, at a glance the system's functionality is obvious, but all descriptions are at a very high level. Further detail can later be added to the diagram to elucidate interesting points in the system's behavior.)

Example: A UCD is well suited to the task of describing all of the things that can be done with a database system, by all of the people who might use it (administrators, developers, data entry personnel.)

The class diagram is the main building block in object oriented modelling. They are being used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be programmed. In the class diagram these classes are represented with boxes which contain three parts: [1] http://upload.wikimedia.org/wikipedia/commons/2/2e/BankAccount.jpg

http://bits.wikimedia.org/skins-1.5/common/images/magnify-clip.pngA class with three sections.

The upper part holds the name of the class

Figure The middle part contains the attributes of the class

The bottom part gives the methods or operations the class can take or undertake

In the conceptual design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the statical relations between those objects. With detailed modeling, the classes of the conceptual design are often split in a number of subclasses.

In order to further describe the behavior of systems, these class diagrams can be complemented by state diagram or UML state machine. Also instead of class diagrams Object role modeling can be used if you just want to model the classes and their relationships.[1]

Structured Approach’s ERD is a graphical notation for high-level descriptions of conceptual data models --especially for relational database systems. Like UML use case diagrams, these ERDs are typically used in the first, "requirements analysis" stage of information-system design. It is used, for example, to describe information needs and/or the type of information that is to be stored in a relational database to address these needs. At the same time, it can be used to describe any ontology (i.e. an overview and classification of used terms and their relationships) or for a certain universe of discourse (i.e. area of interest).

Print Email Download Reference This Send to Kindle Reddit This

Share This Essay

To share this essay on Reddit, Facebook, Twitter, or Google+ just click on the buttons below:

Request Removal

If you are the original writer of this essay and no longer wish to have the essay published on the UK Essays website then please click on the link below to request removal:

Request the removal of this essay.


More from UK Essays

Doing your resits? We can help!