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.
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.
Familiarization or background
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.
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.
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
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
Schedule the design sessions
Conduct orientation and training for design session participants
Prepare the materials, room, and software aid
Conduct the kickoff meeting
Revision of the project scope, objectives and cost
Identify data, process and system requirements
Identify the different system interfaces
Assigning the facilitator to resolve all disputes and issues
Documenting and recording of the whole sessions
Completion of the design documents
Signing off the design documents
Obtain the approval to proceed
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 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.
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.
Does not require a highly qualified expert or highly paid consultant
Very productive in generating ideas
Encourages creative and "out of the box" ideas
Provides an opportunity for widespread participation and involvement
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.
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
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:  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.
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).