Requirements capture

Requirements capture is the process of harvesting the raw requirements of your stakeholders and turning them into something useful. It is essentially the interrogation of stakeholders to determine their needs. This can take many forms, with questionnaires or interviews being the most popular.
The usual output is a 'requirements specification' document which details which of the stakeholder requirements the project will address and, importantly, which it will not.

The focus in requirements capture must be in gathering of information. Keep your ears open and
your mouth shut! Listen carefully to what people want before you start designing your product.
Later you can focus on how things are to be achieved for now you need to find out what must be
achieved.

Requirements capture also needs to be fast. Projects have a tendency to bog down at this stage
and to produce reams of documentation, but no useful output. Requirements capture should not
produce endless tomes detailing the answer to every possible question but should provide enough clarity for the project team so that the objectives are clear.

Requirements capture also needs to be fast. Projects have a tendency to bog down at this stage
and to produce reams of documentation, but no useful output. Requirements capture should not
produce endless tomes detailing the answer to every possible question but should provide enough clarity for the project team so that the objectives are clear.
Questionnaires
Questionnaires are a typical way of gathering requirements from stakeholders. By using a standard set of questions the project team can collect some information on everyone's needs. While questionnaires are efficient for rapidly gathering a large number of requirements their
effectiveness can be limited since it is a one way process. If you don't ask the right questions, you
don't get the right answers. There is also no way to seek clarification or resolve conflict. To resolve this, questionnaires are usually used in conjunction with other methods, such as interviews.
Interviews
The same questions posed in a questionnaire can be put across a table in an interview. The benefit of the interview is that it allows more exploration of topics and open ended discussion on the requirements for the project. It's a two way process.

Interviews can either be structured as single or group sessions. Particular stakeholders can be
interviewed individually or a group session can be used thrash out ideas amongst a larger number of stakeholders (and hopefully obtain consensus). In a group session you can use a formal structure or a more open style where ideas are thrown around, a brainstorming session. The best ideas that survive can be adopted by the project team as part of the requirements.
The down-side to interviews is that they are time and people intensive. Not only must the interview be set up and conducted but minutes must be taken, distributed and reviewed, and it may be necessary to hold one or more follow-up meetings. Using questionnaires and interviews is a common and efficient practice; questionnaires can be distributed beforehand and an overview of the stakeholder’s requirements collected. The interviews are then focussed and directed towards the clarification of those requirements.

User observation
Another method of requirements capture is direct end-user observation or evaluation.
The purpose of user observation is to capture requirements that the end-users may not be consciously aware of. For example individuals using a cheque processing system in a large finance system may conduct a number of manual steps outside of the system that could be automated.
Because they don’t regard these steps as being part of the system they will not mention them when questioned about the incumbent system. Only by direct observation will the development team become aware of the importance of these steps.
You can either use free-form observation or you can take a typical group of end users are set a series of tasks and monitor their processing of these tasks. Notes are made on the way they conduct the tasks, any obstacles they encounter and you could even video tape it (if they agree).
Direct user observation is particularly powerful because, unlike the first two methods of requirements capture, it relies on observed fact and not upon opinions. It is however, the most
resource intensive of the three techniques.
Conflicting Requirements
One or more requirements may contain elements that directly conflict with elements of other
requirements. For example, a performance requirement may indicate that a core system must be updated in real time but the size and scope of the system (as defined by other requirements) may preclude this. Updating such a large system may not be possible in real time.
One of the most effective ways of resolving conflicts between requirements is to impose some form of prioritisation. This allows the potential for negotiation since it provides a basis for assessing conflicting requirements. For example if, from the previous example, the requirement for real time updates was rated at a much higher priority than the inclusion of full customer data, then a compromise could be reached. The main ‘online’ database could contain only the barest essential of customer details (allowing real time updating) and a separate ‘archive’ database could be established which contained customer histories.

Project Planning

Plan to plan. It is always difficult to get people together to develop a plan. The planning session itself should be planned, or it may turn into a totally disorganized meeting like those that plague many
organizations. This means that an agenda must be prepared, that the agenda should be time-limited to
the degree possible, and that people should be kept on track; if someone gets off on a tangent, the
meeting facilitator should get the person back on track as quickly as possible.

The first rule of planning is to be prepared to replan!
• The people who must implement a plan should participate in preparing it. Otherwise, they may feel
no sense of commitment to the plan, estimates for their work may be erroneous, and major tasks may be
forgotten.
• Because unexpected obstacles will crop up, always conduct a risk analysis to anticipate the most
likely ones. Develop Plan B just in case Plan A doesn’t work. Why not just use Plan B in the first
place? Because Plan A is better but has a few weaknesses. Plan B has weaknesses, also, but they must
be different from those in Plan A, or there is no use in considering it as a backup.
The simple way to do a risk analysis is simply to ask, “What could go wrong?” You should do this for
the schedule, work performance, and other parts of the project plan. Sometimes simply identifying risks
can help avert them; if that is not possible, at least you can create a backup plan. One caution: if you are
dealing with very analytical people, they may go into analysis paralysis here. You are not trying to
identify every possible risk—just those that are fairly likely.
Identify project risks, and develop contingencies to deal with them if they occur.
• Begin by looking at the purpose of doing whatever is to be done. Develop a problem statement. All
actions in an organization should be taken to achieve a result, that is, to solve a problem. Be careful
here to identify what the end user really needs to solve the problem. Sometimes a solution is developed
that the project team thinks is right for the client but that is never used, resulting in significant waste to
the organization.

• Use the Work Breakdown Structure to divide the work into smaller chunks
for which you can develop accurate estimates of duration, cost, and resource requirements.
PROJECT PLANNING STEPS
The basic steps in planning are:
1. Define the problem to be solved by the project.
2. Develop a mission statement, followed by statements of major objectives.
Be sure the project really satisfies the customer’s needs, rather than being what the team thinks the customer
should get!
3. Develop a project strategy that will meet all project objectives.
4. Write a scope statement to define project boundaries (what will and will not be done).
5. Develop a Work Breakdown Structure (WBS).
6. Using the WBS, estimate activity durations, resource requirements, and costs (as appropriate for
your environment).
7. Prepare the project master schedule and budget.
8. Decide on the project organization structure—whether matrix or hierarchical (if you are free to
choose).
9. Set up the project notebook.
10. Get the plan signed off by all project stakeholders.

Planning and Control

Managers are supposed to control the application of scarce organization resources to achieve desired results. In a sense, management and control are synonymous.

The question is, what is control? The old connotation implied authoritarianism, domination, the control of
people. Another meaning, however, is comparing progress to planned performance, then correcting for deviations. That is an information systems definition of control. Note that it is your plan that tells you where you are supposed to be; if you have no plan, you have nothing to compare progress against, so without a plan, control is impossible to achieve!
This should be one of the Ten Commandments of management: you must plan in order to control! That is why planning and control have been called Siamese twins—you cannot separate them. Planning is done only so that control can be achieved. No need to do it otherwise. Since control is comparing progress to plan, without the plan there is no control.

What Goes Into a Plan?
The minimum ingredients that should be contained in a project plan follow. It is a good idea to keep these in a looseleaf notebook. Initially, the notebook will contain only the plan. As the project is managed, reports, changes, and other documents will be added, so when the project is completed the notebook will contain a complete history of the project, which can be used by others as data for planning and managing their own projects.

The items that make up the project plan include:
• A problem statement.
• A project mission statement
• Project objectives
• Project work requirements (a list of all deliverables, such as reports, hardware, and software). It is a
good idea to have a deliverable at each major project milestone so that progress can be measured more
easily.
• Exit criteria. These criteria are used to determine when each milestone has actually been reached.
• End-item specifications (engineering specifications, architectural specs, building codes, government
regulations, etc.).
• Work Breakdown Structure (WBS). These identify all of the tasks that must be performed in order to
achieve project objectives. A WBS is also a good graphic portrayal of project scope
• Schedules (both milestone and working schedules)
• Required resources (people, equipment, materials, and facilities). These must be specified in
conjunction with the schedule
• Control system
• Major Contributors. Use a Responsibility Chart for this
• Risk areas, with contingencies if possible

WHAT IS A PROJECT?

What is the difference between project management and managing in general? Aren’t they really the same?
The answer, of course, is no. A project is done only once, whereas most jobs are ongoing or repetitive, and
managing one-time jobs is different from managing ongoing ones. For one thing, the people who work on a
project may be reassigned to other jobs once the project is completed, so the team is temporary. Often the
team members do not report to the project manager on a regular basis, meaning that the project manager has no direct authority over them, a situation that presents its own set of problems.

Quality expert Dr. J. M. Juran defines a project as a problem scheduled for solution. This definition forces us to recognize that projects are aimed at solving problems and that failure to define the problem properly is what sometimes gets us into trouble. Interestingly, when you tell project team members that you want to begin planning a project by writing a problem statement, they tend to say, “We don’t need to do that. We all know what the problem is.”

WHAT IS PROJECT MANAGEMENT?
Project management is the planning, scheduling, and controlling of project activities to meet project
objectives. The major objectives that must be met include performance, cost, and time goals, while at the
same time you control or maintain the scope of the project at the correct level.
Ideally, the scope of a project should remain constant throughout the life of the job. Naturally, this seldom
happens. In most cases the magnitude (scope) of the work increases as a result of overlooked details,
unforeseen problems, or an inadequately defined problem. The most common reason for scope changes is that something is forgotten.

Scope generally increases. In fact, about the only time project scope decreases is when the budget is cut and some of the originally planned work is put on hold. The problem with scope changes is that they tend to be small and incremental; if a number of them occur, the project budget or schedule may suffer. This is a fairly common cause of project failures.
A project manager should advise stakeholders (especially customers) of the impact on the project of a change in scope so that decisions can be made about how to handle such changes. If a customer is told that a requested change will result in a 20% increase in project costs, the customer may opt to defer the change. If the impact is not made clear, the customer may ask for the change, thinking the costs will not increase
significantly, and be very dismayed at the end of the job to learn of the true impact. A project manager has a
responsibility to keep stakeholders informed about the impact of scope changes on the project, protecting
them from surprises at the end of the job and protecting the project manager from being evaluated on original targets rather than on revised ones.
performance: The quality of the work being done. cost: The cost of project work, directly related to the
human and physical resources applied. time: The schedule that must be met. scope: The magnitude of the
work to be performed.
The four project objectives are related to each other by the following equation:

What the equation says is that cost is a function ( f ) of performance (P), time (T), and scope (S). As P and S
increase, cost generally increases. The relationship between time and cost, however, is not linear. As a rule,
cost increases as the time to do the project decreases below a certain optimum time. That is, there exists a
project duration that results in the best performance of all resources. If the duration is shortened, it is often
necessary to pay premium labor rates as a consequence. Further, worker errors often increase, resulting in
costs for corrections, and productivity often declines. Studies have shown that if a knowledge worker spends
twelve hours of overtime on a job, the actual increase in output is equivalent to that normally obtained in two
hours of regular work.
In addition, if project work extends beyond an optimum time, costs increase because people are not working
efficiently. This relationship is shown in Figure 1-1.
Some senior managers believe that if enough people are thrown at a project, it can be completed in whatever
time is desired. This is simply not true, but the idea is the cause of many project fiascos.

A Project Manager’s Survival Guide to Going Agile

When software development project teams move to agile methodologies, they often leave project managers behind. Traditionally trained project managers are confused as to what their new roles and responsibilities should be in an environment that no longer needs them to make stand-alone decisions.

This paper focuses on re-defining the job of project manager to better fit the self-managed team environment, one of the core agile principles. Special emphasis is placed on the shift to servant leadership, with its focus on facilitation and collaboration. Mapping of PMBOK knowledge areas to agile practices is discussed at length. After reading this paper, project managers should have a better understanding of what changes they need to make professionally, and how to make these changes in order to survive the transition to an agile software development approach.

The Movement to Agile Methodologies
Agile software development methodologies such as Extreme Programming (XP), Scrum, Crystal, Lean, etc., are becoming more prevalent in the industry. What is it about these approaches that have companies all over the world casting out their traditional plan-driven methods in favor of an agile process? And how do project managers fit into the new archetype, which favors self-managed teams?
Companies are moving to agile processes because the technology marketplace demands its suppliers be highly responsive to change. In order to compete in the global economy, companies must move quickly to provide solutions to a client base that has more and more choices available to them. Agile approaches promise faster delivery of working code, higher quality, and an engaged development team that can deliver on its commitments. Traditional waterfall, with its long phases and heavy investment in “big up-front design,” lacks the flexibility to swiftly respond to the market.
It’s also about the money. Agile processes can provide a larger return on investment by decreasing the investment in inventory, decreasing operating expenses, and increasing throughput (Anderson, 2004). In other words, by eliminating the time and money spent on designing an entire system – a design that may be outdated before it is implemented, a design that may have numerous pieces that are never even coded – and by eliminating the waste that accompanies heavy process, software development teams are able to provide rapid delivery of value to customers, resulting in greater profits.
Agile methodologies aren’t going to be a fad. The transition to agile processes is a growing trend that will have lasting effects on the industry and the people involved. It’s a different way to work, one that requires greater communication and cooperation from its participants and greater leadership from its managers. In fact, the job titles in use today – manager, director – are illustrative of the traditional command-and-control approach that are now giving way to the new guidance and mentoring method of working with teams. It will be a challenge for many of these managers to release control, as they begin to make the transition to being leaders.

Agile vs. Plan-driven Development

Both agile and plan-driven development recognize the triple constraint: cost, schedule, and scope. But whereas plan-driven development advocates locking down the requirements so that schedule and cost can be estimated, the agile approach says that scope is always changing and therefore schedule and cost should be fixed. This way projects don’t become death marches, and the product is developed in a fashion where it’s in a perpetual releasable state.
This basic shift in focus has a cascading effect on each subsequent practice in both approaches. Planning, executing, and controlling disciplines move from more directive, command-and-control tactics to facilitative, collaborative support. The idea being that if you give the team the tools they need, help them to understand the business problems they’ll be solving, and give them the space and time to complete the job, that they can then be self-directed and self-organizing, and become a fully engaged and motivated team that produces high-quality products at a faster clip. Clearly, for many organizations, this change in tactics also leads to a shift in the culture and in the ways success is measured.
Project managers will find themselves learning how to guide their team in responding reliably to change instead of conforming to plan, and learning how to do this in a completely new environment where the team makes decisions instead of being told what to do. It means more individual responsibility for team members, and more facilitation skills required for the project manager. Most are uncomfortable with their new roles at first, and it is the project manager’s responsibility to build team cohesion and foster good communication. Not everyone is willing to make this paradigm shift, project managers included. But for those who are willing, they’ll find both the process and the new skills they’ve learned to be richly rewarding and well worth the effort involved.

Discover Web Requirements

DISCOVER - This stage guides the development team through designing a prototype and setting goals. At the end of this stage, everyone involved in the project should have a clear picture of which applications are being developed and why.Of the thirteen jm+co rules for Private Web development, five are put to use in the Discover stage.

Rule 1 -

BEGIN WITH THE END IN MIND
It is extremely important to ensure that the driving force behind your prototype application is part of a process that directly produces value for the customer of the organization. These are typically applications that impact the corporate mission or an identified value stream. During the "Build Client Wish List" task, you will review the available opportunities. These drivers and other pertinent issues are quickly identified, so that a prototype can be built that will generate broad-based support and aid team members in setting goals for the project as a whole.

Rule 3 -

THINK ORGANIZATIONALLY, NOT COMPUTATIONALLY
It is very important to select technologies based on goals and needed functionality, not popularity with other organizations. During the "Identify Client Requirements" task, you will identify the specific functions you will require in order to have a successful system. This rule warns us to avoid selecting technologies just because, "everyone else has it". This leads to making decisions based on goals we set considering the specific costs and needs of the organization.

Rule 4 -

UNDERSTAND THE POSSIBILITIES
The members of your development team must understand the technologies involved in your private web project, as well as understanding what is possible today using Internet technologies. The "Identify Project Team" task provides a matrix and guidelines for selecting team members as well as a way of documenting your justifications for selecting each developer. Throughout the methodology, you will find pointers guiding you to where to search on the web for "up to the minute" information on specific cutting-edge topics.

Rule 5 -

KNOW WHERE YOU ARE AND WHERE YOU ARE GOING
During the "Build Client Wish List" you gather some baseline information, which is later refined in the Design stage. Assessing not only technical impacts, but staffing impacts is crucial to the success of the new system.

Rule 9 -

MIX UP YOUR STAFFNo,
this does not mean intentionally confuse people. Rather it means that it is important to get different perspectives from people at different levels and parts of the organization. This rule comes into play in both the "Identify Project Team" and "Identify Client Requirements" tasks. Select your project team from a diverse group and demonstrate your prototype to broad audiences in order to get feedback from as many people as possible. In this way, you will get everyone's needs out in the open where they may be assessed and addressed.

Build Client Wish List

Description

Building the Client Wish List involves the following tasks:- Complete Client Profile Questionnaire - Analyze Industry Information- Perform an Enterprise-wide Analysis What am I doing?During the Complete Client Profile Questionnaire step you will identify the clients' (these can be external or internal clients) principals and collect baseline requirements data. Then you will Analyze Industry Information by gathering information from the principals and other resources. As you Perform an Enterprise-Wide Analysis you will gain an understanding of past organizational issues and project future Internet-related needs in order to ensure integration with other efforts. Why? The first task in the web building process is to get a feel for the immediate needs of the organization. During this task, you will identify an important value stream for the organization and determine how you can improve the process to make the organization more effective. Working through the fact-finding steps in this task will help you to develop an effective prototype and get the project off on the right foot. This task also helps the project manager gain an understanding of what the principals' expectations are going to be with respect to this project. Internal client issues will be uncovered early to allow you time to deal with them effectively. Documentation of this information gathering process will be used later for further discussions and to validate decisions made during the project.What are the risks of not properly performing this step?- Critical client goal or background information may be missing. The Client Profile Questionnaire allows individual principals to give thoughtful and complete input to client goals without the political and timing pressures of a group situation . It draws out information which may have been missed in the initial goal discussion.- You may end up with an ineffective prototype. Since gaining universal support early and showing immediate results are the key to building your Intranet, this could be a mistake that dooms your project to failure.- Your efforts may conflict with other past, present, or future efforts. Has someone developed a site at the departmental level? What other plans are in the works? The Enterprise-wide Analysis helps you ask the right questions and coordinate your efforts with others.

Identify Project Team

Description

Identifying the project team involves the following tasks:- Identify Creative Team - Identify Technical Team - Identify the Content Management TeamIn order to properly Identify the Creative, Technical, and Content Management Teams; you will need to review the client requirements and convert them to skill requirements using the role/skills document template. Each role/skills template has suggested skills for each team. Modify these to suit your specific requirements.Why am I doing it? Finding the right person to fill each role is many times a difficult task. You must, however, begin with the end in mind by knowing which specific skills are needed for each role before making team assignments.What are the risks of not properly performing this step?- The wrong person may be selected for a role. Web site development teams are typically small groups of talented people. Each person typically has specialties within their area of expertise. If a Microsoft NT administrator is tasked with setting up a UNIX environment the project may be seriously impacted. A graphics designer may be skilled at selecting production graphics, but may not understand the art of site concept, layout, or size reduction. The Role/Skills Document Template will aid you in identifying needed skills.- You may assign someone whose time is already over allocated. If your team members are not dedicated to this project, you need to understand the amount of time they can spare and manage the project accordingly. - The wrong mix of people may be assigned to the project. Getting feedback from each potential team member on including the others may help to avoid future conflicts.

Establish Development Environment

Establishing the Development Environment involves the following tasks:- Select a Hosting Option- Set Up InfrastructureWhat am I doing?As quickly as possible, you are setting up the infrastructure for the prototype. This is a quick version of the process you will go through in setting up the production environment, but in the interests of time not all component selection factors are considered.Why am I doing it?The Private Web prototype tends to be very high impact for three basic reasons:1. It solves a specific business problem or improves a value stream process.2. It is produced in a time period that would not be possible using client/server tools.3. It demonstrates the high return on investment that Internet technologies can provide.The information gathering performed at the beginning of the Private Web Development Process helped to ensure that you are building the correct prototype application. The key during this part of the process is speed. While ensuring that the prototype you build is reliable and stable, keep a fast development cycle in mind as a primary objective. Given the competitive market for Internet technologies, investments in software components should be minimal.What are the risks of not properly performing this step?- The prototype may be brought on line too slowly and therefore have less impact.- The prototype may be built using unfamiliar tools. This can slow the development process and increase the likelyhood that an unstable prototype will be produced.

Build Prototype

Building the Prototype involves the following tasks:- Gather Pilot Content - Identify Package Solutions- Select and Create Graphics- Build Prototype InfrastructureWhat am I doing?As quickly as possible, you are building at least one of the candidate prototypes identified in the Enterprise-wide Analysis.Why am I doing it? The Private Web prototype tends to be very high impact for three basic reasons:

1. It solves a specific business problem or improves a value stream process.

2. It is produced in a time period that would not be possible using client/server tools.

3. It demonstrates the high return on investment that Internet technologies can provide. The information gathering performed at the beginning of the Private Web Development Process helped to ensure that you are building the correct prototype application. The key during this part of the process is speed. While ensuring that the prototype you build is reliable and stable, keep a fast development cycle in mind as a primary objective. Given the competitive market for Internet techologies, investments in software components should be minimal.

What are the risks of not properly performing this step?-

The prototype may be brought on line too slowly and therefore have less impact.- Too much of the prototype will be unnecessarily coded by hand, which will slow delivery.- Too much emphasis will be placed on graphical appeal, which could slow delivery. Later in the Design stage, the visual architecture will be designed and implemented. Excessive attention to graphics at this point is a mistake.

Identify Client Requirements

Identifying Client Requirements involves the following tasks:-

Demonstrate Prototype-

Discuss Goals with Principals

At this point the DESIGN stage has begun and a prototype has been created. During this task, you will demonstrate the prototype and solicit as much feedback as possible. Following the demonstrations, you will discuss the goals of the site as a whole using the information gained up to this point in the project. Once goals are determined, they must be mapped to general functions on the site.

Agile Development|Scrum

The Agile family of development methodologies was born out of a belief that an approach
more grounded in human reality would yield better results. Agile emphasizes building working
software that people can get hands on with quickly, versus spending a lot of time writing
specifications up front.

Agile focuses on small, cross-functional teams empowered to make
decisions, versus big hierarchies and compartmentalization by function, and Agile focuses on
rapid iteration, with as much customer input along the way as possible. Often when folks learn
about Agile, there’s a glimmer of recognition – it sounds a lot like back in the start-up days,
when we “just did it”.
One of the fastest-growing Agile methods is Scrum. It was formalized over a decade ago by
Ken Schwaber and Dr. Jeff Sutherland, and it’s now being used by companies large and small,
including Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE,
CapitalOne and the US Federal Reserve. Many teams using Scrum report significant
improvements, and in some cases complete transformations, in both productivity and morale.

For product developers – many of whom have been burned by the “management fad of the
month club” – this is significant. Scrum is simple, powerful, and rooted in common sense.

Scrum Basics

Scrum is an iterative, incremental framework. Scrum structures product development in cycles
of work called Sprints, iterations of work which are typically 1-4 weeks in length, and which
take place one after the other. The Sprints are of fixed duration – they end on a specific date
whether the work has been completed or not, and are never extended. At the beginning of
each Sprint, a cross-functional team selects items from a prioritized list of requirements, and
commits to complete them by the end of the Sprint; during the Sprint, the deliverable does not
change. Each work day, the team gathers briefly to report to each other on progress, and
update simple charts that orient them to the work remaining. At the end of the Sprint, the
team demonstrates what they have built, and gets feedback which can then be incorporated in
the next Sprint. Scrum emphasizes producing working product at the end of the Sprint is really
“done”; in the case of software, this means code that is fully tested and potentially shippable.
Figure

Test Post

hi this is a test post