Requirements Elicitation

Your first responsibility in good requirements management is requirements elicitation and we’re going to give you the 411 on how it works. Requirements elicitation is the method for determining the needs of all the customers and users in the project. This is a very important process, and it requires a collaborative effort between the development team and the client. Our new program helps to facilitate requirements elicitation, making it a straightforward process that allows you to easily organize and prioritize important information.
One thing to keep in mind about requirements elicitation is that it isn’t necessarily just a matter of asking the customer what they want. You have to dig deeper than that, read between the lines, and learn to use your own expertise to understand what they truly need. It’s sort of like when you take your broken-down car to a mechanic. He doesn’t ask if you want him to replace this part or tighten that screw. All he has to know is that you need the car to run – he’ll figure out the rest. So, when you’re meeting with a client, don’t just ask “What do you want?” Instead, ask “What do you need to do?” That way, your client will tell you what they ultimately need to accomplish, and you can help them find the best way to make that happen.
“Why?” is another important question to have in your arsenal. As the customer presents his requirements, don’t be afraid to ask “Why?” when appropriate. Chances are it will help lead the development team and the client to a better understanding of both the problem and the solution.
Take care to learn as much as you can about the client’s current processes. What don’t they like about it now? What do they want to see improve? And don’t just write down what they say and leave it at that. Create a conversation with your client, with lots of give and take. Suggest ideas that come to you on the fly and get their feedback on those ideas.
You should review the full client vision, including future goals and tangential projects, and interview the client stakeholders to get the full set of requirements.

There are often very important unstated requirements that are uncovered and are essential for the project to meet its objectives. As a result the project will meet the written requirements but will not be a success, as the client will be dissatisfied because it doesn’t fit the full vision the client have but didn’t elucidate.

A good way to confirm that you really get when the client means is to write down their requirements and then repeat it back to them for confirmation and to make sure you are correct. Ask more questions to clarify necessary data.

You must attend to the speaker, and then repeat, in your words, what you think the speaker said. This allows the speaker to determine if you really understood. If something is missing, the speaker can further explain the point. Usually when people feel that the other side listens to them, it encourages them to share more details.
When taking requirements notes make eye contact with the speaker, don’t multitask and do other things while listening to the speaker. Do not interrupt the let the other side finish what they say. Clarify the points that you don’t understand, and ask for more details if needed.
Summarize the conversation by organizing the key points and play them back for the speaker.
We are taught that is rude to ask personal questions. People will answer personal questions if they will get them what they want. People will talk all day long about their fears, wants, and frustrations if they feel it will help them to get what they want.

If some requirements or client requests don’t seem reasonable, you should question them. Something that might seem like a simple request from the client may be a huge commitment on our side. We should clarify this to the client and consider the benefit of the request in compared to the cost. Remember, in many cases the client don’t know what is required to develop a feature (this is why they hired you).

Identifying users is another significant component of requirements elicitation, and our program will make that process much easier as well. There are a few different types of users, and the ways in which they differ include: how often they use the product, what features they use, which tasks they perform for their business processes, their level of experience and systems expertise, and their security levels or access privileges. It can be helpful to classify users based on these differences. Keep in mind, though, that some people may belong to more than one class.
Also keep in mind that some users may not even be people. No, robots aren’t taking over the world – yet. I’m just referring to the fact that some applications or hardware components might be interacting with your system, and these could be considered their own class of users.
Other types of users to consider are indirect or secondary users. This group may not be using your application directly, but they might be accessing it through reports or other applications.
Think of as many user classes as you can and build your user class list. Look for groups that have similar needs – those can be considered a major user class with several subclasses.
Once you have determined your user classes, you will want to find user representatives for each class that can provide the voice of the customer throughout the duration of the development process. We’ve found that focus groups comprised of all types of users – both inexperienced and expert alike – are very helpful to the developmental cycle.
Role modeling steps
Use the following steps to identify and select useful set of user roles:
• Brainstorm an initial set of user roles – meet with the client. Each of the participants grabs a stack of cards from a pile placed in the middle of the table. Start with everyone writing role names on cards and then placing them on the table, or pinning them on the wall. When a new role is placed, the author says the name of the new role and nothing more. Since this is a brainstorming session, there is no discussion of the cards or evaluation of the roles. Each person writes as many cards as they can think of. Continue until progress stalls and participants are having hard time thinking up new roles.
At this stage, stick with identifying roles that represent a single user.
• Organize the initial set – now it’s time to organize the roles. Cards a removed around on the wall so that their positions indicate the relationships between the roles. Overlapping roles are placed so that their cards overlap. If the roles overlap a little, overlap the cards a little. If the roles overlap entirely, overlap the cards entirely.
• Consolidate roles – after the roles have been grouped, try to consolidate and condense the roles. Start with cards that are entirely overlapping. The authors of those cards describe what they meant by those role names. Decide if the roles are equivalent. If they are, they can be consolidated into a single role.
You should rip up any role cards for roles that are unimportant to the success of the system. We don’t need user roles for every conceivable user of the system, but we need roles for the ones who can make or break the success of the project.
After consolidating the cards, arrange them on the wall to show relationships between the roles.
• Refine the roles – once we’ve consolidated roles and have a basic understanding of how the roles relate to each other, it is possible to model those roles by defining attributes to each one of them. a role attribute is a fact or useful information about the users who fulfill it. Any information about the user roles that distinguishes one role from another may be used as a role attribute. Here are some examples:
o The frequency with which the user will use the system.
o The user’s level of expertise with the domain.
o The user’s general level of proficiency with computers and software.
o The user’s level of proficiency with the software being developed.
o The user’s general role for using the software.

Serving as an interface between the project’s requirements analyst and the members of each user class are Product Champions. They are vital members of the user communities, collecting requirements from members of the user classes that they represent. Product champs should be enthusiastic supporters of the new system and have a deep understanding of its benefits and its inner workings.
In the event that you are working in a situation where the users are unknown or otherwise difficult to engage, you may have to hire consultants or experts to be surrogates for actual users.
With all of these requirements issues being dealt with, and so many different users and stakeholders in the mix, there are bound to be lots of questions and conflicts arising, right? That’s why you must decide very early on in the project who your decision makers are for requirements issues. When no one is made responsible, then the decisions inevitably fall to the developers, and that really isn’t ideal since they don’t always have the necessary experience, knowledge, and perspective to make the best business decisions. So make sure every group chooses a decision maker right away, and select people who are well-informed on the issues.
For any project, there should always be at least one real user on the client’s team because real users are the ones who know how they need the software to work.
It’s tempting to think that we know what the users want, but no matter how smart we are (and I, for one, am very smart), the reality is that we can’t see the user’s point-of-view, so we really do need their input. Of course we know that sometimes it can be hard to get real users, in which case you need user proxies to represent them. The more user proxies you use, the better, since that makes it more likely that the system you create will meet the needs of a broader range of users.
As you proceed with requirements elicitation, you will find that requirements come from multiple sources, which largely depend on what type of product you’re dealing with. Sources of software requirements include marketing surveys, reports of problems, requests for enhancement of the current system, documents that describe industry standards, documents that describe competing products, events and responses, system requirements specifications, and analysis of user tasks.
During requirements elicitation, you’ll be getting a great deal of the information that you need through user interviews, but there are other simple techniques that you can use as well. Observing users while they interact with software is a great way to gain new insights. Questionnaires are helpful when you want to gather feedback from a large number of users. We’ve also utilized story writing workshops where users, developers, and clients all gather and come up with scenarios, and then ask questions like: “What mistakes might the user make in this instance?” and “What additional information does the user need at this point?”
Requirements elicitation should occur in cycles, with the first round capturing the highest level requirements needed. As the system grows, especially if it is moving in a new direction, you just may find that priorities change or new requirements are revealed. Fortunately our program makes it easy to set and manage these priorities so that your whole team will always be aware of changes.
Both you and the client have a major role in requirements elicitation. The person collecting the requirements, who we sometimes refer to as the analyst, should understand the client’s business vocabulary and become knowledgeable about the client’s business needs and objectives for the system. The information that the analyst collects should be structured into a written software requirements specification, which constitutes an agreement between the developers and the client regarding the qualities, functions, and constraints of the product being built. The analyst is also responsible for explaining the products created from the requirements process.
The customer should also be an active participant, helping the analysts and development team understand his business, taking the time to provide and explain requirements, and describing in detail how they want the end product to function. The customer needs to collaborate with developers in determining priorities, functional requirements, system features, and use cases, providing information in a timely manner and respecting the developer’s cost and feasibility assessments. If the customer requires changes, they should be communicated as soon as possible, following the developer’s process for requirements change requests.
The heart of the matter is that there must be respect and professionalism between all parties involved in the requirements process. If everyone is open to all ideas, prepared to set priorities, honest and fair about costs and impacts, and communicative about needs and changes, then you will be on your way to building the product that the customer desires.
As you can see, this process of requirements elicitation is absolutely crucial because you can’t design a system for your client until you completely understand what problems it needs to solve.
During the requirements elicitation process, you’ll be taking in a lot of info, which should be categorized so that you can document and properly use it when needed. So let’s go over those categories now.
A Business Requirement is anything that describes a financial or business benefit that the customer hopes to gain from the product.
The business requirements represent the top level of the requirement chain. They define the vision and scope for the system. The other requirement types must align with the context and objectives that the business requirements establish.

The scope draws the boundary between what’s in and what’s out. It defines the project’s limitation.

The vision applies to the product as a whole. The scope relates to a specific project that will implement the next increment of the product’s functionality. Scope is more dynamic than vision. It includes the content of each release. The vision includes all the different scopes.

Business requirements describe the primary benefits that the new system will provide to its sponsors, buyers, and users.

Functional Requirements describe behaviors that the system will show under particular conditions, as well as the actions that the system will allow users to take.
User Case and Scenarios are general statements about user goals or business tasks that users must perform. One specific path through a use case is known as a usage scenario. You can find out use cases by asking users what are some of the goals that they have in mind when they’re working with the system.
When a client specifies that only particular user classes may perform an activity under specific conditions, that is what is known as a Business Rule. Business rules are not functional requirements, so you may have to define software functional requirements in order to enforce these rules.
Statements that explain how well the system performs a certain behavior or allows the user to take certain actions are called Quality Attributes.
Then you have Data Definitions, which include definitions of data type, default value, and allowed value.
Constraints are what restrict the developer’s options. Take note of the reasoning behind each constraint so that everyone working on the project knows why it’s important.
And finally there is External Interface Requirements, which describe the connections between your system and everything outside of that system. Whew, that was a long list! But now you have the inside scoop on what requirements elicitation is all about. Obviously it’s an incredibly important process, one that you’re going to want to implement in all your projects right away. You’ll find that our new program streamlines it for you and makes requirements elicitation an absolute breeze.

Requirements Change Control Process

Project change control

It is very rare to define the entire project up front. There might be outside forces that affect the project during it lifetime. Therefore, change is part of the project. It is important to have a process in place that is agreed upon by the client.

Change control is the management of anything that was not in the original scope, requirements, schedule or cost estimates of the project. It involves updating and maintaining the project documents and the resulting changes to quality, risk, cost, schedule etc.
It includes: adding new requirements based on new functionality that is needed. Deleting requirements of features that have been canceled. Schedule changes, fixing errors in the baseline documents.
This can affect the project cost, schedule, requirements documents, risk management, quality management etc.

Submitting a change is done using the ‘Change request’ form. It could be done on paper, digital document or using a software form, that is part of the control management system.

A change request should follow a mini-requirements creating process and go through the stages that were described earlier.

The change request should contain the complete snapshot of the change. It should include the description of the change, the reason for the change, and an explanation of the benefits to be received from the change.

The change request should be sent to the development team for analysis, time and cost estimation and design. It should also be passed to all other stakeholder that might be impacted by this change.

When the process is done, it is very important to update the requirements documents with the changes and notify the teams about the change.

The change-control process
A change-control process lets the project’s leaders make informed business decisions that will provide the greatest customer and business value while controlling the product’s life cycle costs. The process lets you track the status of all proposed changes, and it helps ensure that suggested changes aren’t lost or overlooked. Once you have baselined your requirements, follow this process for all proposed changes to that baseline.

• All requirements changes should follow the process. If a change request is not submitted in accordance with the process, it won’t be considered.
• On design or implementation work shall be performed on unapproved changes.
• Simply requesting a change doesn’t guarantee that it will be made. The project change control board will decide which changes to implement.
• The contents of change database shall be visible to all project stakeholders.
• The original text of a change should not be modified or deleted.
• Impact analysis should be performed for every change.
• Every incorporated requirement change shall be traceable to an approved change request.

There should be a defined team that is responsible to review and approve or decline change requests.
A change request passes through a defined life cycle, having a different status at each stage in its life.

There should be a procedure, known to all, on how to submit a change request.
Once a change request has been submitted, it is evaluated for technical feasibility and alignment with the project’s business requirements and resource constraints.
The appropriate decision makers approve or reject the request change. Once approved, the change request is assigned with a priority level and target date. It is added to the work schedule and assigned to a developer. They approval team notifies the team members who might be involved or needed to modify work products. Affected work products could include the requirements documentation, design description and models, user interface components, code, test documentation, help screens, and user manuals.
Change request form
• Change origin – the person who asked for the change.
• Change request ID
• Change type: defect, enhancement, feature, requirement change.
• Date submitted
• Date updated
• Description – description of the change being requested.
• Priority – the priority in which the change should be implemented. Determined by the change board: low, medium, high, critical.
• Assigned to – the person who is mainly responsible for implementing the change.
• Originator priority – the relative importance of making the change from the originator point of view: low, medium, high, critical.
• Planned release – product release for which an approved change is scheduled.
• Project/product – name of the project in which the change is being requested.
• Feature – name of the feature for which the change is being requested.
• Response – free text of responses made to the change request. Multiple responses could be made overtime (message board).
• Title – the one line summary of the change.
• Status – the current status of the change request.
• Verifier – the name of the person who is responsible for determining whether the change was made correctly (test).

Requirements Review Process

The requirements, documentation process. Isn’t just about writing and recording information. You also have to review the requirements. Anytime someone other than the author of a software requirements, document examines the product for problems. A peer review takes place. Reviewing requirements. Documents is a powerful technique for identifying ambiguous or unverifiable requirements. You can also detect bugs in the design. During the review process, before they’re developed, it costs five times more to fix a bug at the development stage than in the requirement stage.
There are both formal and informal types of reviews. The informal types include a peer desk check where you ask a colleague to look over your work product, a pass around where you invite several coworkers to look at the document at the same time and a walkthrough where you describe the document and ask for comments on it.
A formal peer review on the other hand follows a well defined process. A formal review produces a report that identifies the material, the reviewers in the review team’s judgment as to whether the product is acceptable. The review produces a summary of the defects found and the members of a formal review share responsibility for the quality of the review.
Digging deeper into the review process gets us to the inspection process. Any software work product can be inspected, including requirements and design documents, source code, test documentation, and project plans. Inspection is a well defined multi-stage process that involves a small team of trained participants who carefully examine a work product for defects and improvements. Participants in the inspection should represent four objectives. The author of the work product, the author of any predecessor work product or specification for the item being inspected. The people who are responsible for work products that interface with the item being inspected. And finally, the people who do work based on the item being inspected, such as a developer, a tester or a project manager, we recommend limiting the team to no more than six participants.
There are four major roles in the inspection process. The author creates or maintains the work product being inspected. The moderator serves as the inspection leader, planning the inspection with the author, coordinating activities and running the inspection meetings. The reader paraphrases the SRS one requirement at a time with the other participants then pointing out potential defects and issues by stating the requirements in her own words, the reader provides an interpretation that might differ from that held by the other inspectors. The final role is the recorder who uses an issue tracking software to document the issue raised. And the defects found during inspection meetings.
The inspection happens in stages, starting with the planning phase, when the author and moderator plan the inspection together, deciding who should participate, what materials the inspectors will need to receive before the inspection meeting and how many meetings they’ll need to cover the material.
The next stage is the overview meeting in which the author describes the background of the material that will be inspected.
The preparation stage happens prior to the inspection meeting and it involves each inspector examining the product to identify possible defects and issues that should be raised up to 75% of defects are found during this phase. So keep a sharp eye.
Then it’s time for the inspection meeting. During this meeting, the reader leads the other inspectors through the SRS, describing one requirement at a time in his own words, the inspectors bring a possible defects and the other issues while the recorder captures them on a form that becomes the action item list for the author. The purpose of the meeting is to identify as many major defects in the document as possible. The meeting shouldn’t last more than two hours, but if you need more time, schedule another meeting at the end of the meeting, the team will decide whether to accept the requirements document as is accept the minor revisions or indicate that major revisions are needed.
The rework stage is where the author spends time reworking the requirements after the inspection meeting and follow up is the final step in which the moderator works with the author to ensure that all open issues have been resolved and errors have been corrected. The entire process ends when all of the issues raised during the inspection have been addressed or any changes in the document have been correctly made, or when the document has been checked into the project’s configuration management system
To help inspectors look for typical kinds of errors in the products that they inspect, develop a defect checklist for each type of requirements, document. This draws the inspector’s attention to historically frequent problems.
There are a lot of challenges associated with requirements review, and fortunately our program will help make the process much easier. There are a few tips we’d like to pass along to you though, to help you with other aspects of the process. For instance, we know that large requirements documents like a several hundred page SRS document can be seriously daunting. So to avoid overwhelming the inspection team, try performing incremental reviews throughout the requirements development, identify high risk areas that need a careful look and use informal reviews for less risky material, definitely consider using several small teams to inspect different portions of the material. Also establish several small teams to inspect the SRS in parallel and combine their defect lists.
And even if you have a long list of potential participants for requirements inspections, try not to let your inspection team get too large because that complicates things like scheduling meetings and reaching agreement on issues. Make certain that every participant is there to find defects, not to be educated or to protect a political position. Also, we recommend that you decline the participation of people who duplicate a perspective that’s already covered.

Requirements Documentation

Now let’s talk about Requirements Documentation. The result of the effort that you put into requirements development is a documented agreement between the customers and the developers about the product that’s going to be built. It’s important that the requirements are fully documented in the way that best captures the process, which is why you want to use software that is specifically designed for requirements documentation.

Software requirements can be represented in a number of different ways. For instance, you can use documents that utilize well-structured, clearly written, natural language; you can use graphical models that illustrate system states, transformational processes, data relationships, logic flows, or object classes; or you can represent the requirements with formal specifications that define features using mathematically precise formal logic languages. Structured natural language, accompanied by graphical models, continues to be the most practical way for the majority of software projects to document their requirements.

As you know, business objectives describe the business problem that’s being resolved – or the business process that’s being improved. You’ll want to summarize the important business benefits that the product will provide in a quantitative and measurable way. State the factors that have the greatest impact on achieving success and specify the measurement criteria to assess whether or not the business objectives have been met.

When the requirement documentation is done, we recommend that you send it out to all of the stakeholders, to let them know what the output of the process will be. Ask them to review it. The truth is, people are always far more committed to making the process successful if they feel they are involved and know the plan.

From a beautiful sports car to the perfect juicy burger, all the finest things in life have certain characteristics that combine to make them great. Excellent requirements have a set of characteristics too. One such characteristic is that they’re Complete. Each requirement needs to fully describe the functionality to be delivered. It’s got to contain all the information necessary for the developer to design and implement that feature.

Another characteristic of excellent requirements is that they are Correct. Each requirement must accurately describe the functionality that needs to be built. The reference should be the source of the requirement or the person who asked for it. It could be a user, for instance. Only users can determine the correctness of user requirements, which is why they should always be involved in the process. Bear in mind that a requirement that conflicts with another requirement is not correct.

Excellent requirements are Feasible. It has to actually be possible to implement each requirement within the known capabilities and limitations of the system. The developers should work with the people that define the requirements to make sure that they’re doable.

Each requirement should be Necessary. Every requirement should be for a feature that the customers really need or are required for compatibility with an external system or regulations.

Excellent requirements are also Prioritized. Assign a priority to each functional requirement to indicate how essential it is to a particular product release. Prioritizing is vital because, if all the requirements are classified as equally important, then it’s hard for the project manager to respond to budget cuts, schedule overruns, new requirements added during development, or other factors that require updates to the development plan.

Requirements should be Unambiguous. Write requirements in simple, concise, and straightforward language so that nobody reading them could possibly misinterpret them. If requirements are not explained precisely and completely, there is the danger that developers will end up trying to fill in the blanks on their own. Requirements that are too ambiguous could also end up creating different expectations on the part of stakeholders, leading to disappointment with the development results.

Requirements should be independent. If a Requirement’s development is dependent on the development of other requirements, it might cause prioritization and planning problems. For example, suppose a customer has selected as high priority a requirement that is dependant on a low priority one. In this case, the low priority feature would have to be developed as well, before developing the high priority feature.
When there is no way to avoid dependencies, you can combine the dependant feature into one larger independent requirement, or find another way of splitting them.

And the last characteristic of excellent requirements? Verifiable. Try devising a few tests or other verification procedures to figure out whether or not the product properly implements each requirement.

There are several requirements attributes that should be recorded during the documentation process. These attributes include: (he numbers them on his fingers)
– Unique ID number
– the date the requirement was created
– its current version number
– the requirement status – such as: Requirements, Design, Development, or Complete
– the origin and source of the requirement
– the requirement type: for example, Mandatory, Optional, or Future version
– the names of the requirement author and the person responsible for ensuring that the requirement is developed successfully.
– the owners of the requirements who will make decisions about proposed changes
– any subsystems to which the requirement is allocated
– a product release number to which the requirement is allocated
– And approval status: That is, Approved, Pending, or Rejected
Other requirements attributes that should be recorded during documentation include:
– The Objective, which is the business objective to which this requirement is related to.
– And also the implementation priority

You have to break down the project into processes, or user stories. Each process represents a sequence of actions that users take to complete a task that will help them to achieve a business objective. For example: In our drapes ecommerce website: one process could be searching for drapes. Another process is selecting drapes and adding them to the shopping cart.

Each process groups a set of features that enable the product user to use the system to complete the task. So you break down each process or story into a list of features. You’ll find that it’s easier to list the features by the order that they’ll be used by the user. For instance, take the process of selecting drapes and adding them to the shopping cart: one feature will be a search engine that enables the user to search for drapes based on criteria like color, size, type of drapes, and fabric. Another feature would be selecting the characteristics of the drapes before adding them to the shopping cart: selecting the color, the size, accessories that can be added to the drapes, and so on.

Once you’ve listed the features of each process, it’s time to start drilling down into each feature. Write a clear description of the way the feature should work and what components it should include, such as buttons, screen layout, field types, value ranges, and so on. The description should be very detailed and very well-organized so that the developers will know exactly what needs to be done. You don’t want to leave anything for them to guess. Usually developers don’t talk to users and clients, so they don’t always fully understand the client needs. If you leave them with too much room for interpretation, then they might take the product in the wrong direction. As a result, the team could end up developing a product that is completely different from what the client expected to get, and then you would need to start the development process all over again or make changes to the product after it has been developed. Obviously that would cost you a great deal of money, waste a lot of time, and leave you with extremely angry clients. So that’s why it is very important to have a clear, detailed, and organized description of how the features should work.

Use simple language, avoid complex sentences, and assume the readers have no basis knowledge of the project. Use consistent terminology, utilizing the same terms throughout the document so that nobody will get confused. If the feature description includes too many items and starts to get too long, you might want to consider dividing it into a few smaller features. The idea is that a feature description should be about a specific functionality. But you want to keep the balance of not going into too much resolution. You don’t define a requirement for every button that you have on the screen. But if a feature includes a few smaller features, each smaller feature has a different role, and requires detailed definition, you should break it into several smaller requirements.

Let’s take for example the shopping cart feature. This is a large part of functionality that should be divided into smaller requirements. For instance: the option to add items to the shopping cart is one requirement. The option to edit or delete items from the shopping cart is another feature. How the shopping cart should be displayed on the screen, with page layout, buttons and fields, is a separate requirement. The payment process is also a feature that we should define independently. So I list the shopping cart requirements under a feature group called Purchasing Process. Each feature in this group will help the user to complete a small part of the purchasing process, until the user can accomplish her business objective of buying the drapes.

Here are three letters you should know: SRS. That stands for Software Requirements Specification. Functional requirements are documented in an SRS, which fully describes the expected behavior of the software system. The SRS also includes non-functional requirements like performance goals and the descriptions of quality attributes. The SRS states the functions and capabilities that a software system must provide and the constraints it must respect. It’s the basis for all subsequent project planning, design, coding, and testing. Customers, the marketing department, sales staff, project managers, the software development team, the testing group, maintenance and support staff, documentation writers, training personnel, legal staff, and subcontractors all rely on the SRS. Needless to say, it’s really important! To document these requirements, you’ll need to use an SRS template, which you can find by clicking on the SRS template below.

Requirements Management software, like Elementool, creates the SRS automatically based on the requirements that you submit to the system. You can even create shorter versions of SRS with a set of a few specific features, in case you want to discuss these features with your team. You do that by simply selecting the features you want to include in the SRS and then the software generates the document for you.

The requirements documentation process isn’t just about writing and recording information. You also have to review the requirements. Any time someone other than the author of a software requirements document examines the product for problems, a peer review takes place. Reviewing requirements documents is a powerful technique for identifying ambiguous or unverifiable requirements. You can also detect bugs in the design during the review process before they are developed. It costs 5 times more to fix a bug at the development stage than in the requirements stage.

There are both formal and informal types of reviews. The informal types include a peer ‘deskcheck’, where you ask a colleague to look over your work product; a ‘passaround’, where you invite several co-workers to look at the document at the same time; and a ‘walkthrough’, where you describe the document and ask for comments on it.

A formal peer review, on the other hand, follows a well-defined process. A formal review produces a report that identifies the material, the reviewers, and the review team’s judgment as to whether the product is acceptable. The review produces a summary of the defects found and the members of a formal review share responsibility for the quality of the review.

Digging deeper into the review process gets us to the inspection process. Any software work product can be inspected, including requirements and design documents, source code, test documentation, and project plans. Inspection is a well-defined multistage process that involves a small team of trained participants who carefully examine a work product for defects and improvements. Participants in the inspection should represent four perspectives: the author of the work product, the author of any predecessor work product or specification for the item being inspected, the people who are responsible for work products that interface with the item being inspected, and the people who will do work based on the item being inspected (such as a developer, tester, or project manager). We recommend limiting the team to no more than six participants.

There are four major roles in the inspection process. The Author creates or maintains the work product being inspected. The Moderator serves as the inspection leader, planning the inspection with the author, coordinating activities, and running the inspection meetings. The Reader paraphrases the SRS one requirement at a time, with the other participants then pointing out potential defects and issues. By stating the requirements in her own words, the reader provides an interpretation that might differ from that held by other inspectors. The final role is the Recorder, who uses an Issue Tracking software to document the issues raised and the defects found during inspection meetings.

The inspection happens in stages, starting with the Planning phase, when the author and moderator plan the inspection together, deciding who should participate, what materials the inspectors need to receive before the inspection meeting, and how many meetings they’ll need to cover the material.

The next stage is the Overview Meeting, in which the author describes the background of the material that will be inspected.

The Preparation stage happens prior to the inspection meeting, and it involves each inspector examining the product to identify possible defects and issues that should be raised. Up to 75% of defects are found during this phase, so keep a sharp eye.

Then it’s time for the Inspection Meeting. During this meeting, the reader leads the other inspectors through the SRS, describing one requirement at a time in his own words. The inspectors bring up possible defects and other issues, while the recorder captures them on a form that becomes the action item list for the author. The purpose of the meeting is to identify as many major defects in the document as possible. The meeting shouldn’t last more than two hours, but if you need more time, schedule another meeting. At the end of the meeting, the team will decide whether or not to accept the requirements document as is, accept the minor revisions, or indicate that major revisions are needed.

The Rework stage is where the author spends time reworking the requirements after the inspection meeting. And Follow-up is the final step, in which the moderator works with the author to ensure that all open issues have been resolved and errors have been corrected. The entire process ends when all of the issues raised during the inspection have been addressed, or any changes in the document have been correctly made, or when the document has been checked into the project’s configuration management system.

To help inspectors look for typical kinds of errors in the products that they inspect, develop a defect checklist for each type of requirements document. This draws the inspectors’ attention to historically frequent problems.

There are a lot of challenges associated with requirements review, and fortunately our program will help make the process much easier. There are a few tips we’d like to pass along to you, though, to help you with other aspects of the process. For instance, we know that large requirements documents, like a several hundred page SRS document, can be seriously daunting. So to avoid overwhelming the inspection team, try performing incremental reviews throughout requirements development. Identify high risk areas that need a careful look, and use informal reviews for less risky material. Definitely consider using several small teams to inspect different portions of the material. Also establish several small teams to inspect the SRS in parallel and combine their defect lists.

And, even if you have a long list of potential participants for requirements inspections, try not to let your inspection team get too large because that complicates things like scheduling meetings and reaching agreement on issues. Make certain that every participant is there to find defects, not to be educated or to protect a political position. Also, we’d recommend that you decline the participation of people who duplicate a perspective that’s already covered.

Finally, we should talk a bit about the project change control process. As requirements evolve and grow during development, projects often exceed their planned schedules and budgets. Frankly, these plans aren’t always based on a realistic understanding of the size and complexity of the requirements. And frequent requirements modifications just make the problem worse. To manage scope creep, you should begin with a clear statement of the project’s business objectives, strategic vision, scope, limitations, success criteria, and expected product usage. Evaluate all proposed changes and requested features against this reference framework.

Creeping requirements include new functionality and changes that are presented after the project requirements have been baselined. The problem is not that requirements change, but that late changes have a big impact on work already performed. If every proposed change is approved, it might appear to project stakeholders that the project will never be completed. It’s kind of like when my husband and I recently re-did our kitchen. There were many times during the process that I thought ‘Oh, maybe it would be nice to also add this on,’ or to change the type of tile along the counter. But for those changes to work, we would have had to start again from scratch. And not only would that have been a pain in the neck, it also wasn’t in our budget.

Of course some requirements evolution is legitimate or unavoidable. We know all too well that business processes, market opportunities, competing products, and technologies can change during the time it takes to develop a product. But uncontrolled scope creep, in which the project continuously incorporates new functionality without adjusting resources, schedule, or quality goals, has a harmful effect. A small modification here, an unexpected enhancement there, and soon the project has no hope of meeting the planned schedule. So you should evaluate every proposed requirement or feature against the business objectives, product vision, and product scope.

The most effective technique for controlling scope creep is being able to simply say no. Philosophies such as ‘The customer is always right’ are fine in the abstract, but you pay a price for them. If you find it difficult to say ‘No,’ try saying ‘Not now’. At some point you have to freeze the requirements for a specific release or you will never complete it.

It’s very rare to define the entire project upfront. There might be outside forces that affect the project during its lifetime. For that reason, change is part of the project. It’s important to have a process in place that’s agreed upon by the client. Change Control is the management of anything that wasn’t in the original scope, requirements, schedule, or cost estimates of the project. It involves updating and maintaining the project documents and the resulting changes to quality, risk, cost, schedule, and so on. Change control includes adding new requirements based on new functionality that is needed, deleting requirements of features that have been canceled, fixing errors in the baseline document, and scheduled changes.

Submitting a change is done by using the ‘Change request’ form. It can be done by using a software form, such as Issue Tracking, that is part of the control management system. A change request should follow a mini-requirements creating process and go through the stages that we described earlier.

The change request should contain the complete snapshot of the change. It needs to include the description of the change, the reason for the change, and an explanation of the benefits to be received from the change. Your Requirements Management software should be able to track all that information. It should also be classified as a new change or a correction to existing requirements. Send the change request over to the development team for analysis, time and cost estimation, and design. Pass it around to all other stakeholders who might be impacted by this particular change. It should then be approved and added to the development plan. When the process is done, be sure to update the requirements records in your Requirements Management software with the changes and notify all teams about the change.

This clip ends the Requirements Management section of the program. Next we are going to learn how to estimate and manage task schedule. Stay tuned.

Personal Time Management

And we want to talk to you about personal time management. This subject is a little bit of a detour from our more specific project management program. But we believe that time management is an issue that affects everyone,

We don’t want to say that they need to be really good at something and that there is no quick fix. Instead, we should say that we are going to offer them an easy way to improve their time management and show them simple things that they implement right away and get great results.

The best methods for upping productivity are based on two key objectives: The first objective is to capture all the things that need to be done – now, later, someday, big, little, or in between – into a logical and trusted system that’s outside of your head and off your mind. The second objective is to discipline yourself to make front-end decisions about all the inputs that you let into your life, so that you’ll always have a plan for next actions that can be implemented at any moment.

Most people these days will tell you that they have too much to do and not enough time to get it done. We’ve enhanced our quality of life in so many ways, yet, ironically, we nearly kill ourselves with stress by taking on more work than we have the resources to deal with.

That’s why time management is so important, because it’s really a kind of stress management.

Have you ever wondered why you can’t seem to shut down your brain at night when you’re trying to fall asleep? Why are so many thoughts running through your mind all the time?

Let me explain how stress is created. it’s not just the big problems that create stress. All of the little unresolved tasks that we have to deal with sit at the back of our heads, subconsciously creating tension. If you put your mind’s attention on something that needs to be done, and then don’t complete it because it’s low on the priority list, your mind will have already created an open process that keeps running in the back of your mind, and is going to keep bothering you to complete the task. Worse of all, it takes up your energy and prevents you from having a clear focus on your more important tasks.

It’s kind of like your Windows Task Manager. When you open Task Manager, you see that there are a lot of processes running in the background – processes that you didn’t even know existed. Many of them don’t do anything for days, but there they are consuming your computer memory and causing it to run slowly. But if you shut down the processes that you don’t use, then it frees up the memory and your computer will run faster.

All these open processes create stress. So how do we handle with all these processes and how do we minimize stress?

The key is to clear the open processes from our mind by having something else managing them.

Now we come to the question of how you process this information. First of all, you need to determine what the item is and what you’re going to do about it. For example, maybe you have letters from the bank or the government. Or maybe you received an email from a supervisor about a new company policy.

Ask yourself: Is this item actionable, yes or no? If no action is needed, then you have three options. One, it’s trash – so throw it away. Two, no action is necessary now, but you might need to do something later on, so you incubate this item. Three, the item is potentially useful information that you might need later on, so you can classify it as a reference item.

If it is actionable, then something has to be done. So, ask yourself: What project or outcome have I committed to? And also, what’s the next action required? If it’s about a project, then capture that outcome on a project list. That will remind you that you have an open process. Determining the next action is a critical step for anything you’ve collected. The next action is the next physical activity that has to be done in order to move the current situation to completion.

Once you’ve decided on the next action, you have three options. Option One: Do it. If that action will take under two minutes, you should do it then and there. Option Two: Delegate it. If you aren’t the right person to do the job, assign it to the appropriate person or entity. Option Three: Defer it. If the action is going to take more than two minutes, and you are in fact the right person to do it, then you can track it for later on a Next Actions list.

To keep organized, do one of the following to your “no action” items: Throw them out, mark them for later reassessment, or file them away so that they can be located and referred to at another time if needed.

To manage the actionable items, you’re going to need a storage place to put the tasks, a calendar, a list of reminders of next actions, and a list of reminders of things that you’re waiting for. You’ll also need a list of projects. Projects are things that need to be completed by following a set of tasks. Hiring a new employee, decorating a room, and building a new version of software are all types of projects.

As soon as you attach a “should” or “need to” to an item, it becomes incomplete. Decisions that you still need to make about whether or not you’re going to do something are already incomplete.

In order to manage this inventory of open processes, you have to capture it in containers that will hold them until you have time to decide what they are and what you’re going to do about them. Then you need to empty these containers regularly to ensure that they remain good tools for collecting.

The fact that you haven’t put an item in your basket doesn’t mean you don’t have it. You need to be sure that everything you need is collected somewhere other than your head.

Now there are many kinds of collection tools, and they can be physical or digital. For example, a basket, writing paper, a Word document, an email, or issue tracking software are all different types of collection tools.

There are three main factors that make this collection actually work. One, every open process has to be in your collection system and out of your head. Two, you must have as few collection buckets as possible. And three, you have to empty them regularly. These collection tools should be part of your lifestyle. Keep them nearby so that wherever you are, you can always collect a potentially valuable thought.

And emptying them regularly really is very important. Otherwise, there’s no point. You don’t necessarily have to complete the item in your basket or in that Word document, but you do have to take it out of the container, decide what needs to be done with it, and if it’s still unfinished, then organize it into your system. Not emptying your containers is like having garbage cans that never get dumped. You would just have to keep buying more and more cans to hold all your trash.

How to Take Charge of Your Projects

Hi, I’m Allison
And I’m Bob
What we are about to show you will radically change your thinking about how you invest your time, and what’s really important when it comes to making money and running your projects.



We’ve all been there. Not enough time, no solid schedule, poorly defined goals and objectives, no formal plan, out of control scope creep, miscommunication between people that are involved in the project, etc.
As a result, projects are delayed, time is wasted, clients are angry, your company’s reputation is damaged and you lose customers, people are frustrated and stressed out, team members have to work extra hours to catch up, morale goes down, and employees lose confidence in the company.
If you’ve invested time and money in trick after trick — such as using different project tools, begging and threatening, shouting, motivating team members, holding group discussions, adding more people to the team, and working more hours — but nothing has worked, I would ask you to consider this program.
You’ve been investing in tools and services because you want a better income. A better life for your family. Freedom and independence. But tools alone are useless without solid foundations. You need strategies for using tools.
You’ve been focusing on tools and solving problems instead of focusing on creating strength and power that can be leveraged.
Think about it like this: let’s say you have the fastest car in the world in your garage. But you don’t know how to drive. The car will be useless to you because you don’t know how to move it.
But if you are an excellent driver, even a slow car will be able to get you from one place to another.
We are going to show you how to take charge of your projects and run them in a simple way that will enable you to complete them on time, starting today.
This can boost income now and bring you the high-caliber clients that you want to attract. It can make your company more efficient and competitive.
And, the good thing about it is that you don’t need any special background, education, or skills to use this.
If you don’t take aggressive action once you’ve seen the path, we can’t help you.
Success is for people who take action. Mediocre people follow the herd and wait passively for things to maybe change in the future. You are not like that.
We are going to show you how to drive your projects and you’ll be able to use this knowledge with any tool that you currently have.
We at Elementool have been helping companies with their projects for over 12 years, and we’ve gained a tremendous amount of insight into what it takes to manage projects efficiently and effectively. In this program, we’re going to pass on a set of extraordinary yet simple-to-use skills that can give you the edge that you need to succeed. And what you’ll discover is that once you’ve mastered these skills, you’re going to have way less stress on your mind and way more free time to spend the way you want.
But first, let me tell you how everything started.
Elementool was founded 12 years ago by Yaron Sinai.
Before starting Elementool, he worked for a software company as a project manager, met people who were also project managers, and realized there was no good and easy solution for running projects.
Yaron learned programming at home and worked in the evenings and on weekends for 6 months straight to build the website. At the beginning it was a very simple issue tracking and help desk solution.
The website was offered for free to people who wanted to use it to run projects. It was the first web-based software of its kind in the world.
A few months later, Yaron realized that Elementool required his complete attention, so he quit his job to run the website full-time. But it wasn’t as easy as he thought it would be. He had to move back with his parents because he couldn’t pay the rent. No job, no car, and living with his parents was tough. He couldn’t get any dates with women. That made things even worse.
He tried to raise funds from investors. And, wanting to look professional he rented a laptop from a nearby computer store every time he went to a meeting with investors, because he didn’t have enough money to buy a laptop computer. Each time he stepped out of a meeting, all he cared about was the fact that he had just wasted $40 on the laptop, instead of getting something to eat. After a few meetings like that, Yaron realized that he was wasting his time and money, so he decided he would grow it on his own.
And grow it did. Soon Yaron hired a group of programmers who developed additional products and added more features to make the system more sophisticated. People were happy with the new web-based solution and the company continued to grow.
Over the 12 years since Elementool was founded, we have worked with thousands of companies, some of them the largest companies in the world, and helped them run their projects.
During that time, we’ve realized that a lot of good managers are struggling themselves and not understanding the right way to run projects. And I bet you can relate to what I’m talking about.
But… it’s not your fault.
There are many books about project management, but, let’s face it, who has time to read 400 pages books when there is barely any time to finish the things you need to do today? And even when the project manager is knowledgeable about how to manage projects, usually the team of developers, testers, managers, and clients have no knowledge in project management methodologies and that creates miscommunication between the different project stakeholders, leading to frustration and project failure.
Let me give you and example: Tracking the time that team members spend on tasks is very important. It enables the project managers and the team to see how the project is progressing, if there are any delays that need to be addressed, or any changes that need to be made in order to keep the project on track.
The project manager knows that, but the team, who might be a group of excellent programmers who have no knowledge in project management and are not aware of the importance of time tracking, might feel like big brother is watching them when team members are asked to report the time they work on assignments. As a result of not knowing the true reason behind this request, they object and refuse to report their time. This type of miscommunication between the project manager and the team leads to arguments, frustration, and project delays.
This is why it is so important for everyone on the team, including developers, testers, managers, and even clients, to be familiar with all the stages that are involved in the project development cycle.
So we’ve done the work for you.
In the past 18 months we’ve conducted extensive research. Read dozens of books, run surveys, and received a lot of feedback from our clients about their problems in the way they run their projects. That helped us to gain an understanding of the challenges that companies face and enabled us to come up with a solution that will help companies have control over their project management process. We want to share our knowledge and expertise in the project management field with you to help you improve your life.
We’ll be covering a lot of ground during the program, guiding you through some very important concepts. But one of the best things about Elementool’s Project Management Formula program is that you will start noticing results right away. As you begin adopting the practices we show you, you’ll immediately see improvements in your work and life.
So, what are you getting from us?
We are offering a 6-week program. Each week you will get a set of short video clips about a specific topic. All it requires is 30 minutes a week of your time to watch these videos. The six major sections that we will be covering in this program are Requirements, Estimating, Scheduling and Planning, Time Management, The Learning Process, and The Project Management Formula.
The first section, Requirements Management, breaks down the requirements phase for you. This is a crucial part of project management that gets ignored far too often, so we are going to start you off on the right foot by explaining the whys and hows of good requirements management.
That will be followed by The Learning Process, which we think you will find truly eye-opening. In that module, we reveal some little-known truths about how our minds take in information and process change. Some people think that, to do their job well, they only have to know the technical aspects of how to perform their tasks. But we believe that to get to the next level professionally – to find greater success – you need to be able to think beyond the obvious. It’s important to understand how the mind works so that you can create positive changes with your team members and within yourself.
The third section, Estimating, is where you learn how to create and provide the best possible estimates for your clients and for your team. We will show you different methods for doing this that you will want to put into action right away. Best of all, they are easy to understand and easy to implement.
Our fourth section, which focuses on Time Management, offers a wealth of information and tips on how you can ensure that your valuable time is used to its best advantage. In that section, we have a terrific game that’s really going to open your eyes about some unexpected realities of managing time.
After you play that game, I promise you’ll never look at multi-tasking the same way again.
In the fifth section, Scheduling and Planning, you’re going to find out practical, easily applicable ways to schedule your projects and keep them on track as you go along. You will also discover in this section that good project management involves managing expectations.
Finally, in the last section, we’re going to show you the Project Management Formula. This is an easy 5 step system for running projects that we’re really excited about, and that you will be able to start using straight away.
Step 1 – Define project objectives and collect requirements
Step 2 – Define the priority of the requirements and features
Step 3 – Planning iterations
Step 4 – Running iterations
Step 5 – Present the product to the client
It’s an awesome program, isn’t it? If you can get your current process to be 5% more effective, how much would it be worth to you? How about 10%, 20%, or 35% more effective?
Take a piece of paper and write down a number.
If you are guaranteed to be able to become 30% more efficient and be able complete projects on time, what would that be worth to you?
Write down a number.
Now think about it this way:
On average, a person in the industry receives an annual salary of $100,000. Now let’s say that you can become 30% more efficient as a result of using this program. This is an annual cost saving of $30,000 each year!
Don’t worry, we are not going to charge you $30,000 per person for this program. We won’t charge you $3,000 and not even $300.
The cost of this program is only $197 per person. Yes, that’s right. Only $197.
We give you this discount because we believe that the program will make a big positive change for you and we would like you to buy it without being worried about budget issues.
Let’s say you’ll use only one little tip you learned in our Project Management Formula program that will make you 1% more efficient. This is a cost savings of $1000 on the first year alone. This little change already covers the cost of the program 5 times.
And it gets even better. At the end of the program we’ll collect video testimonials from clients who bought it. If you send us a video testimonial of how you used the Project Management Formula program and how it helped you to improve the way you run projects, and we decide to use your testimonial in our marketing, we will give you your money back.
Yes, that’s right, you will get Elementool’s Project Management Program for free!
At this time we are offering the Project Management Formula program only to Elementool’s clients. This means that you need to have an active paying Elementool account to be able to buy the program. We want to show our appreciation to our loyal clients by giving them access to the Formula before everyone else does, to give them a competitive advantage.
This is a time sensitive offer only to our clients and will end soon. Then the price will go up significantly and the Formula will be offered to the public. So I suggest that you hurry to sign up today by clicking on the Sign Up button below.
Not only that, we are offering you a Full-satisfaction guarantee. If you are not fully satisfied with this program within the first 4 weeks, you can contact us and get your money back. No questions asked.
So, click on the Sign Up button below now.
There is nothing for you to lose! Buy the program. If it doesn’t work for you, just cancel it and we will give you your money back.
There is one thing we need to clarify: Nothing in these videos should be taken as a promise for potential income. We can guarantee that you’ll be happy with the product and if you are not, you can cancel it and get your money back within 28 days of purchase.
We cannot guarantee that you’ll have any kind of results like other people had. Your results are unique to you. This program is designed for educational purposes only.
Mark Twain said: “Twenty years from now you’ll be more disappointed by the things you didn’t do, than by the one you did do. Throw off the bowlines. Sail away from safe harbor. Explore. Discover.”
Here you can explore and discover with safety. You have my guarantee.
So just click on the Sign Up button below now and start the first step to a better life.

How to Eliminate Stress



Hi, it’s Alison again. People often ask me if I know a good way to eliminate stress in life. Think about how much more fun you would have if you could relieve the stress that you have in your everyday life. You’d be less worried and you’d be much happier and healthier. Well, I do know of a way to eliminate stress, and I’m going to share it with you. It’s actually very simple. Before I share this awesome stress elimination technique with you, I’d like to talk about a related subject. If you want to succeed in something that you do, you need to have two things. The knowledge of how to achieve your goal and the tools that enable you to achieve it.

You need to have both and you can’t achieve your goals with only one of these factors. Let me give you an example. Let’s say you want to drive somewhere. You need to have two things, the knowledge of how to drive or driver’s license and a tool for driving, which is a car. You can’t drive somewhere if you only have one of them. You can’t drive somewhere if you only know how to drive a car, but you don’t have a car, and you can’t drive somewhere if you have a car, but you don’t know how to drive. You’ll be able to move the car but you’ll probably hit something quickly and have an accident.

It’s so obvious that we hardly ever stop to think about it. Same goes with Project Management. You need to have the knowledge of how to run projects, and you need the set of tools that will enable you to actually run the projects. That will take me to the stress elimination technique in a minute. If you have the tools to run projects, but you don’t have the knowledge of how to do it, you’ll start having accidents pretty quickly in the form of project delays, scope, creep, et cetera. This is why we, at Elementool offer you both the knowledge and the tools.
The knowledge comes in the form of our Project Management Formula Program, which is a five-step system for running projects successfully from beginning to end. The tools are the Elementool Project Management Software. Together, they give you a complete solution that will allow you to achieve your goals. Now, back to the stress elimination technique.

First, I’m going to give you the knowledge of how stress is created and how you can prevent it. After that, I’m going to give you the tools that will enable you to eliminate and prevent it. I’m going to start with a short clip from our Project Management Formula Program that explains how stress is created and how you can eliminate it. Here it is.
Most people these days will tell you that they have too much to do, and not enough time to get it done. We’ve enhanced our quality of life in so many ways, yet ironically, we nearly kill ourselves with stress by taking on more work than we have the resources to deal with.

That’s why time management is so important because it’s really kind of stress management. Have you ever wondered why you can’t seem to shut down your brain at night when you’re trying to fall asleep? Why are there so many thoughts running through your mind all the time? That’s stress. Now, let me explain how stress is created. It’s not just the big problems that create stress, all of the little unresolved tasks that we have to deal with sit at the back of our heads, subconsciously creating tension. As soon as you attach a should, or a need to, to a task, it becomes incomplete. Decisions that you still need to make about whether or not you’re going to do something are already incomplete.

If you put your mind’s attention on something that needs to be done, and then don’t complete it because it’s low on the priority list, your mind will have already created an open process that keeps running in the back of your mind. It’s going to keep bothering you till you complete that task. Worst of all, it takes up your energy and prevents you from having a clear focus on the more important tasks.

It’s kind of like your Windows Task Manager. When you open Task Manager, you see that there are a lot of processes running in the background. Processes that you didn’t even know existed. Many of them don’t do anything for days but there they are, consuming your computer memory and causing it to run slowly. If you shut down the processes that you don’t use, then it frees up the memory of your computer, and it will run faster.

All these open-end processes create stress. How do we handle all these processes and how do we minimize stress? The key is to clear the open process from our mind by having something else managing them.

Usually, the reason something is on your mind is because you want the situation to be different than what it currently is. The problem is, you haven’t yet worked out exactly what the intended outcome is. You haven’t decided what the next physical step is, and you haven’t put reminders of the outcome and the action required into a system you trust.

Until you do all that, your brain will refuse to put the matter to rest. You can try to fool the people around you by acting like everything’s okay but you can’t fool your own mind. Only it knows whether or not you’ve come to the conclusions you need. Until you clarify your thoughts, make the decisions, and store the data in a system you can trust, your brain will keep nagging you about the next step and adding to your stress.

To manage the actionable items, you’re going to need a storage place to put the tasks, a calendar, a list of reminders of next actions, and a list of reminders of things that you’re waiting for. You will also need a list of projects. Projects or things that need to be completed by following a set of tasks. Hiring a new employee, decorating a room, and building a new version of software or all types of projects.

In order to manage this inventory of open processes, you have to capture it in containers that will hold them until you have time to decide what they are and what you’re going to do about them. Then you need to empty these containers regularly to ensure that they remain good tools for collecting.

The fact that you haven’t put an item in your basket doesn’t mean you don’t have it. You need to be sure that everything you need is collected somewhere other than your head.

Now, there are many kinds of collection tools and they can be physical or digital. For example, a basket, writing paper, a Word document, an email, or Issue Tracking software, are all different types of collection tools. It’s important that the tools have a good reminder system that you can trust. Once you set up a reminder, you move the responsibility of this task to the reminder system. This enables you to close the process in your mind and reduce the stress.

Okay. Now that we have the knowledge about stress causes and how to prevent it, let me introduce the tools that will help you to eliminate it. Let’s say you have a task that you need to complete and you want to take it off your mind and put it in a system so you won’t stress about it. First, you log into your Elementool Issue Tracking account. Then, you create a new issue and type in the description of the task and how it should be solved. When you’re done with this step, create a reminder that will remind you to complete the task. Elementool will manage the remembering part for you. When the due date comes, if the task is not completed by then, Elementool will send you a reminder regarding this task.

This way, your mind will remain stress-free. Cool and simple, isn’t it? This is a small example of what we offer you and how much it can improve your life. The Project Management Formula offers a six-week program. Each week, you’ll get a set of short video clips about a specific topic. All it requires is 30 minutes a week of your time to watch these videos. The six major sections that we cover in this program are Requirements, which explains how to collect and write requirements and define project objectives. The Learning Process, this section describes how we learn and create habits. It will show you a simple system that will improve your learning speed and help you to create positive habits.

Estimating, this is where you learn how to create and provide the best possible estimates for your clients and for your team. Time Management, here you’ll find a wealth of information and tips on how you can ensure that your valuable time is used to its best advantage so you can achieve more in less time. Scheduling and Planning, you’re going to find out practical, easy ways to schedule your projects and keep them on track as you go along. The Project Management Formula, this is an easy five-step system for running projects from start to end that you’ll be able to start using straight away.

On the tool side, we offer you the Elementool’s Project Management System, which includes Issue Tracking for managing your project tasks and the team’s daily workflow. Help Desk, for running customer support and making your clients happy. File Sharing, for sharing files online and saving time. Test Cases, for making sure everything is tested and no bugs are slipping through the cracks. Requirements Management for making sure the project is developed according to what your clients want. Scheduling, for managing the project plan and schedule, and making sure tasks are completed on time. Conference, for running online meetings and approving communication. Amazing, isn’t it?

I think this entire deal is a game-changer. This is what I would like to offer you. You’ll sign up for Elementool’s Project Management System, which includes the seven tools that I mentioned just now for one year with unlimited users for only $2,519. As a bonus of signing up, I’m going to give you free access to the Project Management Formula Training Program for 50 people on your team. Usually, the price of the Project Management Formula is $497 per person, times 50, this is a bonus of $24,850. I want to give you this bonus because I want you to be successful.

We at Elementool love our clients, and we want to help you and share our knowledge with you. Now, I bet you said to yourself, “This is too good to be true. There must be a catch.” Well, you’re right, there is a catch. This offer is only valid for 24 hours. It’ll expire soon, so you better act fast. Click on the Sign-up button below now.

Requirements Elicitation: Drilling Deeper for Important Details

Your first responsibility in good requirements management is requirements elicitation and in this section I’m going to give you the information you need to elicit great requirements from your first interaction with the client and on through the life of the project itself.

To be clear on our definition before moving forward, “requirements elicitation” is defined as the method for determining the needs of the customers and users in the project, and the project success objectives.

This is a very important process, as one might imagine, and it requires a collaborative effort between the development team and the client. The Project Management Formula helps to facilitate requirements elicitation, making it a straightforward process that allows you to easily organize and prioritize important information.

One thing to keep in mind about requirements elicitation is that, contrary to what most companies assume, it isn’t necessarily just a matter of asking the customer what they want. You have to dig deeper than that, read between the lines, pay attention to details, really, really listen and learn to use your own expertise to understand what they truly need.

The process is sort of like when you take your broken-down car to a mechanic. He doesn’t start out by asking if you want him to replace this part or tighten that screw. All he really has to know is that you need the car to run – he’ll figure out the rest.

You need to remember that the client came to you because you are the expert in your field. So they expect you to come up with a solution to the business situation that they are facing.

The same process can be applied across a variety of industries and with clients small, medium, large or even extra-large. Good requirements elicitation should be transferable, scalable and, ultimately, repeatable. So, when you’re meeting with a client, don’t just ask an open-ended, detail-blocking question like, “What do you want?” This invites the client to solve the problem for himself which, after all, is not why he came to you.

Instead, drill down deeper and ask “What do you need to do?” That way, your client will tell you what they ultimately need to accomplish, and you can help them find the best way to make that happen. Remember, the project is about finding solutions to specific needs, not trying a scattershot approach to solving all needs.

Also, don’t assume that every client knows exactly what they want. Drilling down to create a more accurate project description helps both parties determine the true need as well as a realistic solution. Skipping this vital step can shortchange you both.

Product Requirements

Every project begins with requirements.

Although this step is very important, it is often neglected by companies because people see it as a “waste of time.” Both the developers and clients want to get right to writing the software code because then they feel that the project is progressing, but the result of poor requirements is having to make changes to the system later in the project and sometimes even starting the project all over. And this is a waste or precious time, money and resources.

Not defining the project’s requirements and business objectives is considered to be the number one reasons why projects fail.

Clearly, we must learn the requirements before starting the project. In other words, what does the client/customer require? That is the original question upon which the rest of the project hinges. If you don’t know what the customer really wants, then you’ll be managing the wrong project or, just as bad, managing the right project in the wrong manner.

        Many companies trust the client to know what he wants. Unfortunately, clients generally only know what they “think” they want and rarely work through to the end result. One of the most important aspects of project management is getting to the requirements first so that the rest of the project goes smoothly.

       Careful planning, questioning and soliciting are critical to the requirements process, and that is the groundwork we’ll be laying in this first, critical section.

Projects aren’t just comprised of a beginning, a middle and an end but dozens, even hundreds, of working parts. The more “parts” you’re forced to work with, the more challenging the project can be. But if you can nail the requirements before even getting started on the project itself, the challenges you’ll face later will be both less problematic and less frequent.

The Power of Partnerships: Working Together Versus Working Alone

But you don’t have to do it alone anymore. In a period of 18 months myself and the rest of the team at Elementool, Inc. have conducted extensive research, read dozens of books, run surveys, and received a lot of feedback from our clients about their problems in the way they run their projects.

That helped us to gain an understanding of the challenges that companies face and enabled us to come up with a solution that will help companies have control over their project management process. We want to share our knowledge and expertise in the project management field with you to help you improve your life.

We’ll be covering a lot of ground in this book, guiding you through some very important concepts. But one of the best things about Elementool’s Project Management Formula is that you will start noticing results right away. As you begin adopting the practices I show you, you’ll immediately see improvements in your work and life. That’s because the tools are simple, step-by-step and easy to follow:

Six Sections for Success!

What, exactly, will The Project Management Formula give you? What I am offering you in this book are six sections for success, the last of which – the Formula you’ve been hearing so much about – will provide you with the final five steps, or solutions, that will kick your project management into overdrive!

The six major sections that we will be covering in this book are:

  1. Requirements
  2. The Learning Process
  3. Estimating
  4. Time Management
  5. Scheduling and Planning
  6. The Project Management Formula

The first section, Requirements, breaks down the requirements phase for you. This is a crucial part of project management that gets ignored far too often, so I am going to start you off on the right foot by explaining the “why’s” and “how’s” of good requirements management.

That will be followed by our second section, The Learning Process, which I think you will find truly eye-opening. In that lesson, I reveal some little-known truths about how our minds take in information and process change.

Some people think that, to do their job well, they only have to know the technical aspects of how to perform their tasks. But at Elementool we believe that to get to the next level professionally – to find greater success – you need to be able to think beyond the obvious. It’s important to understand how the mind works so that you can create positive changes with your team members and within yourself.

The third section we’ll cover together, Estimating, is where you learn how to create and provide the best possible estimates for your clients and for your team. I will show you different methods for doing this that you will want to put into action right away. Best of all, they are easy to understand and easy to implement.

The book’s fourth section, which focuses on the extremely crucial skill of Time Management, offers a wealth of information and tips on how you can ensure that your valuable time is used to its best advantage.

In the fifth section, Scheduling and Planning, you’re going to find out practical, easily applicable ways to schedule your projects and keep them on track as you go along. You will also discover in this section that good project management involves managing expectations.

Finally, in the last and most pivotal section of the book, I’m going to teach you The Project Management Formula. This is an easy 5-step system for running projects that we here at Elementool are really excited about, and that you will be able to start using straight away. The five steps of “the Formula” are:

  • Step 1: Define project objectives and collect requirements
  • Step 2: Define the priority of the requirements and features
  • Step 3: Planning iterations
  • Step 4: Running iterations
  • Step 5: Present the product to the client