software testing – Elementool Blog

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 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.

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:

Requirements
The Learning Process
Estimating
Time Management
Scheduling and Planning
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

Instant Messaging

Instant messaging has become common in our daily routine. So we have decided to offer it as part of Elementool to help you improve your communication with your team members. Especially if they are located someplace else.

To start a new conversation using the Instant Messenger, please follow these steps:

• Click on the ‘number of users’ online link at the top of the page to display who is currently logged in to the account.
• Click on the name of the user to start an Instant Message session.
• The Messenger window will be displayed on your screen.
• Type your message and click on the keyboard Enter button to send it.

When someone starts a new conversation with you, you will see a red flag next to the ‘number of users’ link.
Follow these steps to join an instant message session:

• Click on the ‘number of users’ online link at the top of the page.
• The person who sent you the message will be marked on the user list.
• Click on the user’s name to open the messenger window.
• Type your reply in the text box and click on the keyboard Enter button to send it.

As you can see, Instant Messaging is easy and can make the communication with your team faster and more efficient.

How to Submit Issues Faster

Hi, I’m Allison, and I’d like to tell you about new options that we added to the Field Dependency feature. This is a very helpful feature that allows you to quickly locate and select relevant information when filling out a form.

The Field Dependency feature enables the creation of relationships between fields in such a way that a dependant field’s value list is determined based on a value selected in the source list.

For instance, let’s say that you have two fields on a form: State and City. The State field lists all 50 states in the U.S., and the City field lists the 10 largest cities in each of those states. Currently, without using Field Dependency, the State field list shows all 50 states and the City field displays a long list of 500 cities in those states. So if a user wants to choose their city from that list, they need to scan through all 500 to find the one they want.

However, by using the Field Dependency feature, the process becomes much easier. It allows the person to first select their state in the State field. At that point, the Dependency rule automatically filters the city list so that the City field only displays the 10 cities from the selected state. This means that the user can simply select the appropriate city from the list of 10 rather than poring through a long list of 500.

To access the Field Dependency feature, you should go to Control Panel, click on Edit Issue Form and then click on ‘Edit Dependencies’.

Click on Add New Rule to add a new rule.

In Step 1, select the source field that triggers the Dependency rule.
In our example it was the State field.

In Step 2, select the target field that is being changed based on the rule.
In our example it was the City field.

In Step 3, define the rules.
For example:
Select State = New York.
Select cities in New York State.

Click on the Add button to save the rule.

You can repeat these steps to create additional rules for these fields.
When you’re done, click on the Save button to save the rule.

We added two new options to the Field Dependency feature:
• The ability to make a field required based on the value of a certain field.
• The ability to hide fields based on the value of a certain field.

Let me explain how these new options work:

The first option enables you to make fields required based on a value of another field.
For example:
I would like to make the City field required when selecting a State value to make sure that when a person fills out the form and selects a State, they also select the city.

To define the city as a required field, move it to the Required Fields list on the Dependency setup form.

The second option is to hide fields based on a Dependency rule.

For example:

I have a field on the form called Country with a list of country names.
When a person selects a State, they should not select Country. To prevent the person from selecting the Country, I hide the Country field when a state is selected.

To define this rule drag the Country field to the Hidden Fields list.

As you can see, the Field Dependency feature makes filling out and submitting forms much easier and far less time-consuming.

How to Link Different Parts of The Project Stages

Today I want to explain how to link between different parts of the project stages.

A project is never just one thing. It includes many tasks and items that – if you do everything right – come together to form a single whole and a successful end result.

Each project is performed in stages. You have to first define the requirements of the features that you want to develop over the course of the project. Then you have to break down each requirement into workable tasks. When the tasks are completed and the features have been developed according to the established requirements, you must run test plans to locate any potential bugs. If you find any bugs, you report them for fixing so that you can ensure that the entire project works according to plan.

Clearly this is a complex process and it requires you to keep track a lot of information along the way. And if all that information isn’t tracked correctly, your project can turn into a total mess very quickly. A poorly tracked project means you have a chaotic work situation, frustrated developers, massive delays, and, ultimately, an angry client. Needless to say, you want to avoid a nightmare like that.

To keep a project running smoothly, you want to make sure that every aspect of it is connected. That way, tasks and tests don’t fall through the cracks, get ignored, and create trouble in your development process. The best way for you to keep everything connected is to use Elementool’s record linking feature. Elementool makes it easy for you to link all of the various project components together, so you can track each item along the way.

Now let’s talk about exactly how you utilize Elementool to link those components.

As you know, Elementool offers a full set of tools that helps you run the different stages of the project.
We enable you to write feature descriptions using the Requirement Management system, then you can break down each feature description into workable issues and assign them to your team members. At the same time, you can define the testing plan by using Test Cases to write tests for the different features in your projects.
All these parts are linked together.

Let’s say for example that we build a shopping cart for the website.

We will create a feature description in Requirements Management that will describe how the shopping cart should work.
Then we define issues for the specific parts of the shopping cart. This way the developers can start developing it.
Finally, we write the test cases that we should run to make sure the shopping cart is bug free.

Using the Link Issue feature, we can link the Requirements to the Issues and Test Cases.
Under the feature list in the Requirements Management, we can see the issues and Test Cases that are part of each feature.
This way everything is grouped together and we can see the exact status of each part of the project.

If you still don’t have Requirements Management or Test Cases, you should click on the Update Now button below to add these services to your account to make sure your projects are run properly.

File Attachment and Form Customization

In this clip I would like to introduce two new updates that we’ve added to the new Issue Form and also talk about an important topic – Backup.

The first update brings some cool new options to the file attachment feature.
When attaching files, you can now see the files you just uploaded before submitting them to the system.
This way you can make sure that you attached the correct files. For example, when attaching a screenshot, you want to make sure you uploaded a screen image and not an embarrassing picture from your last vacation.
If you change your mind about the file, you can easily delete it by clicking on the delete button. All done before updating the issue.

By the way, did you know that you can increase the file attachment size limit from 1MB to 50MB by adding File Sharing to your account?
Adding File Sharing is easy. Simply go to Control Panel (only administrators have access to the control panel).
Click on Edit Accounts.
Go To Manage Account List and add File Sharing Premium to your account.
Click on Update when done.

The second update is in the form’s customization option.
We received feedback from clients asking us to bring back the option to display short fields in three columns in the main section of the form as used to be done on the old issue form.
So we did. Now you can have three columns of short fields right at the center of the form, giving you additional customization flexibility.
You can add fields to this section by simply dragging and dropping them into the field containers.
So easy!

Lastly, I’d like to talk about an important subject – Backup.
As you may know, our privacy policy dictates that when you delete information from your account, it’s being deleted immediately and permanently from the website.
This means that if you trash issues, remove a field from the form, delete users from the account, and so on, these changes are permanent.
Sometimes we receive calls from clients asking us to restore data that they deleted by accident. For example, a few weeks ago a client deleted one of the fields on her issue form and called to ask us to restore the field.
Well, unfortunately we can’t do that because in order for us to protect your privacy, data cannot be restored once deleted.

But there is a solution for this.
Elementool enables you to download a self backup file with all the information from your account. You can download your backup file at any time. And we recommend that you do that at least once a week. This way, if something has been deleted by mistake, it can be restored from the backup file.
To download a backup of your account, please follow these steps:
Click on Control Panel.
Click on Edit Accounts.
Click on Download Database.
Select the account you wish to backup and click on Download.
Elementool will send you a link to the backup file.
There, all done! Now just make sure to do these backups regularly so you don’t lose anything important.

In a few weeks I’ll send you another update about the new search feature that we’ve been working on.

Stay tuned!

The Power of Integration

Hey Allison I have a question for you. Can you give me one reason why I should choose Elementool?

Sure, I can sum it up in one word: Integration.

What do you mean?

I’ll explain: Elementool offers you a full set of tools that helps you to take charge of each stage of the project. It includes:
• Issue Tracking – for assigning tasks to team members and developing them according to priority.
• Scheduling – for managing the project plan and schedule, and for making sure tasks are completed on time.
• Help Desk – for running customer support and making your clients happy.
• Requirements Management – for making sure the project is developed according to what your clients want.
• Test Cases – for making sure everything is tested and no bugs are slipping through the cracks.
Now, let’s assume that you have 20 people on your team and you buy these products from other vendors.
One vendor offers Issue tracking for $20 per month per user.
Another vendor offers Help Desk for $25 per month per user.
A third vendor offers Scheduling for $19 per month per user.
And so on.
You end up with a monthly expense of about $2000 for 20 people.

Wow, that’s a lot of money.

I know! And there’s more. You need to use the different vendor APIs to integrate between the different tools. So your developers have to spend their time working on tool integration instead of working on your projects. And after a while, your tool bundle looks like this.

Oh, boy, that’s not good. So what do you offer? I remember that you mentioned something about integration earlier.

Well, Bob, that’s exactly right. Elementool offers you all the tools as one integrated system. This means that you don’t even need to use any APIs to integrate them. They come together and work together.

That sounds really great. But, wait, how much does it cost?

The entire system, which includes Issue Tracking, Scheduling, Help Desk, Requirements Management and Test Cases, only costs $149.95/month with unlimited users.

Really, unlimited users? Do you mean that I don’t pay per user and can actually have as many users as I want?

Exactly.

So how much would I pay if I had 200 users, or 2,000 users, or… 25,674 users?

$149.95/month.

That’s awesome! How can I start using Elementool?

I’d like to let you try Elementool for 30 days for free. Just click on the Free Trial button below to get started now.

How to Create Test Cases

Hi, I’m Allison.

In this short clip I’m going to talk about test cases. I’ll explain how test cases can save your company’s reputation and show you how you can create test cases in just a few minutes.

So why do we need test cases in the first place?
Test cases have an important role in protecting your company’s reputation.
We’re all familiar with software products that are released to the market with critical bugs that are later being discovered by the clients. This can be very embarrassing but also can cost your company a great deal of money and even hurt people’s lives.

Let me give you two examples:
• The infamous iPhone 4 bug was estimated to cost Apple $175 million for free cases in addition to multiple class action lawsuits filed by thousands of disgruntled users.

• The 2003 Northeast power blackout was caused by a software alarm system failure. 50 million people lost power for two days; the event caused 11 deaths and cost $6 billion.

These kinds of events can be prevented by using a test cases system.

A test cases system is the backbone of the software testing process and enables you to define a list of tests to make sure every part of your software is properly tested before it is released to the client.

You don’t want to leave anything to chance. I’m sure your team is a group of highly trained professionals, but we are all human. And humans sometimes forget things.
You want to make sure that everything has been tested during software testing and nothing has been forgotten.
As a manager, people won’t remember how many bugs you have found. Even if you caught a thousand bugs during the testing process, what people will always remember is the one bug that slipped through the cracks and was found by your client.

Elementool enables you to create a closed circuit system that locks the bugs inside and prevents them from slipping through the cracks.

The process of writing test cases is as follows:

You start by creating a test list tree and defining the different features for each requirement.
Then you break down each feature into a list of tests. When you’re doing this, you want to think about all the ways that people might use each feature and then look for places where it could potentially fail.
You create a list of tests for correct behavior that the system should support, to make sure that the product does what it’s supposed to do.
Then you create a list of tests of incorrect behavior that the system should not support, to make sure the system can handle events that don’t follow its business rules.

I’ll give you an example:
Let’s say you build a credit card payment page.
You want to create a list of tests that check if the page can accept valid credit card details of the different credit card companies.
You also should create a list of tests that check if the page rejects invalid credit card details, such as credit cards that have expired, characters instead of credit card numbers, and so on.

Each test needs to have a defined list of steps for the tester to follow in order to complete them. Remember, you don’t want to leave anything to chance, and you want to make sure nothing is overlooked. The tester will mark the status of each test as Passed or Failed and then submit the test results into the system. Doing this allows the testing manager to keep track of the progress of the testing.

Make sure to give a priority to each test, running the highest priority tests first before working your way down to the lowest priority. You want to focus on first finding those high priority bugs, the ones that do major damage like crashing the software. If the schedule allows, you can then move on to the lower priority issues.

In the event that a bug is discovered during testing, the tester should submit a new issue to the issue tracking system that describes the bug. The new issue should be assigned to the project manager that needs to add it to the iteration plan and schedule, and then it will be assigned to the appropriate team members for fixing.

Elementool enables you to link bugs to tests, this way it’s easy to track the progress of the bugs that have been reported. It also prevents testers from submitting duplicate bugs, if a similar bug has already been reported for this specific test.

So that you can protect your company’s reputation by always finding bugs before your clients do, I would like to offer you the Tests Cases and Issue Tracking software right now for only $119.99/month.
Added to this, I’m going to give you two extra services for free:
• Scheduling – for making sure your project is developed according to plan.
• Requirements Management – for making sure the project is developed according to what your clients want.

So click on the button below and upgrade your account now!

How to Create an Agile Backlog in 2 Minutes

It’s Allison here again.

In this clip I’m going to talk about Backlog.
Most likely you’ve heard this term in the past.

I’ll explain what an Agile Backlog is, the advantages of using an Agile Backlog, and show you how you can setup your own Backlog using your Elementool account.

A Backlog is a list of the tasks or issues that the team needs to complete in a specific iteration. It shows you the progress of the development and the status of each task.

It’s a lot like a car GPS. It shows you how fast you are going, how much you’ve traveled so far, and how much you still have ahead.

Each row on the Backlog represents an Iteration.
Each column represents an Issue Status.
Usually at the beginning of the iteration, all the tasks will be under the Open status column, which means that they are not completed yet and need to be worked on.

In the middle of the iteration, tasks will change their status and location on the Backlog. Some will be in progress, some complete, and a few still open.

The ultimate goal is to reach the end of the iteration when all the tasks are in the Complete column.

To setup a Backlog in your Elementool account, you should follow these steps:

1. Define all the tasks in the Issue Tracking account and assign them as Status ‘Open’.
2. In your Scheduling tool, define a project and iterations.
I explained in detail how to setup projects and iterations in previous clips and I suggest that you check them out. You can find the links to these clips below.
3. Add the Issue Tracking tasks to the iteration by using the ‘Add Issue’ option.
4. Once all the Issues have been added to the iteration, let’s go back to the Issue Tracking’s Welcome page.
5. If you don’t see the Backlog, add it by clicking on any item’s Edit button, check off the ‘Show Backlog’ option, and click on Save.
6. Now the Backlog is displayed and the Issues are automatically added to it. You can see their status and progress on the Backlog.

I would like to offer you the Issue Tracking and Scheduling for only $119.99/month.
Added to this, I’m going to give you two extra services for free:

• 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.
So click on the button below and upgrade your account now!