Requirements Management – 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 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.

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.

All You Need to Know About Requirements Management

Requirements Management is one of the most critical stages in the success of projects.
71% of software projects fail because of errors and oversights made during the requirements phase.

In the following clips we will show you all you need to know about requirements management to help you prevent project failure and delays.
These are a few of the topics that are covered in the clips:
– How to collect requirements from stakeholders
– How to create user stories and interviews
– How to document the requirements using requirements management software
– How to handle the change requests submitted by stakeholders during the development process
– Tips on how to avoid scope creep and how to make sure everything stays within your control

And much more… You don’t want to miss it!

Hello, my name is Allison, and I would like to welcome you to the project management training program. Thank you for signing up – you will definitely be glad that you did. In fact, not only do I want to thank you, but I really want to congratulate you because you’re now embarking on a new program that is going to help you get to the next level professionally.
Hi, I’m Bob and I want to welcome you aboard as well. Allison and I are going to be teaching you the ropes, guiding you step by step through this amazing new program, and we’ll be telling you a lot of great insider secrets as we go. You’re going to see exactly how easy it is to get started using these tools right away. And once you begin utilizing this program, you’ll find that it makes your work a lot easier, and, as a result, it makes your life a lot better.

What we want to talk about first today is Requirements Management, because that is where every project should begin. Not a lot of people realize this, but up to 71% of all software projects fail because of errors and oversights made during the requirements phase. In fact, I can give you an example from my own life that may sound familiar to some of you: Last month I planned my little girl’s 6th birthday party. I decided it would have a princess theme, so I bought a pink cake and sparkly decorations and princess-themed favors. It looked perfect, if I do say so myself. But when my daughter came downstairs and saw everything, she was sad. She loves animals and she had wanted a zoo theme for her birthday. What was my mistake? Not finding out what my “client” wanted ahead of time.

Just like you need to be attentive to the needs of your family at home, you have to focus on your clients’ needs at work. And, frankly, one of the things that I love about this program is that it makes my work easier so that I actually have more time to spend at home. Requirements management in particular is all about helping you to do your job more efficiently. I’ve been serving as a Project Manager for years and I can tell you from personal experience that one of the most common problems for people in my field is the failure to document and understand the client’s needs, which is Requirements Management 101.

Failure to figure out what the requirements are upfront means trouble. The project vision and scope aren’t clearly defined, requirements aren’t prioritized, developers encounter ambiguities and missing information when coding and start guessing what the client wants. The result is often an unhappy client.
Some studies have shown that for each dollar invested in finding and fixing errors during the requirements phase, you can save as much as $200 later on to correct that same problem after implementation. Think how much you save by catching problems early on! So requirements management is the first, and maybe the most important step in successfully completing a project. Yet many people overlook it completely.

The major benefit of requirements management is that it defines the project and provides a framework that enables the tracking and completing of the project’s progress and objectives.
When you implement requirements management, you see the advantages right away. It helps control project schedule and costs, improves communication between members of your team, allows for faster development, reduces unnecessary rework during the late stages of development, and ultimately increases customer satisfaction. I won’t name any names, but the days before I was in charge, I worked under a few project managers who were lousy at requirements management and it made for a miserable working experience. There was conflict among team members, deadlines weren’t met, and the end product was often all wrong.

Simply put, requirements management makes your job easier and it makes your client happier. And, fortunately, you are about to learn a very easy-to-use formula that is going to help you with that aspect of project management.

In the requirements management section of the program here, we are going to take you through step-by-step and teach you everything you need to know. It’s very simple and we’re going to break it down for you so that you can be using it immediately and start seeing great results right away.

We’ll be covering three main areas in this section: requirements elicitation, requirements documentation, and the change control process. In requirements elicitation, we will teach you how to collect requirements from stakeholders, and we’ll show you how to create user stories and interviews. For requirements documentation, we will explain how you document the requirements using requirements management software and you will learn how to create SRS (or Software Requirement Specification). Then we’ll get to the change control process, where we show you how to handle the change requests submitted by stakeholders during the development process. We will also give you tips on how to avoid scope creep and how to make sure everything stays within your control.
Be aware that the requirements phase isn’t a linear process. There are a number of steps, and you may need to repeat some of them, adding and editing more information along the way.
The first step is Initialization, where you gather requirements from the start-up documents, starting with the information that is available to you. This includes defined project goals and objectives, the identification of stakeholders and users, and identified major constraints and benefits. For this process, it is extremely helpful to use requirements management software, which will give you all the tools you need for listing requirements. You will want to use different categories, such as product and project name, security, environmental, and so forth. You will also want to specify the requirement type as mandatory or optional, and prioritize it as critical, high, medium, or low.

Step 2 involves interviewing the key players to gather more information, drilling down for needs that were not expressed in the initial documents, and clarifying existing requests by establishing important information such as priority level. List and prioritize the stakeholders that you plan to interview based on the importance of information that they can give you for writing the requirements. Keep in mind that there are different levels of interviews. You can interview individual people or a group. You can even do a workshop that involves different teams. You can also just observe how people do their work and build the requirements list based on an analysis of their process. For the interviewers, offer recommendations of books that advise on how to ask questions.
The third step is analysis, which involves collecting the information gathered so far, putting it together, and looking for conflicts or missing details. During this stage, the project manager collects the data that he gathered in the interview phase and starts putting the pieces together. First, he should start with the high level picture and determine what the final solution should look like. Then, he can start breaking down each high level requirement into smaller ones, connecting them, assigning them priority, and determining their level of importance to the project. The project manager should be sure to evaluate the risk factor for each requirement at this time.

Step 4 is Documentation, the point at which you put everything together, clearly written and organized, in a detailed and comprehensive requirements document. The document should place all requirements together in a clear flow from high level down to the lower level. These requirements should be as specific as possible, including classifications such as mandatory, required, and so on. The requirements should be measurable and achievable, so that you can determine if they have been achieved. They should also be results-oriented. Define the expected result of each feature. It is easier to build the requirements in a tree structure, dividing them into categories and sub-categories. Each requirement item should have a title and description, with the description written in a story format.

This is the initial stage of the project, in which people may commit to certain activities and resources. As you probably well know, people have a tendency to forget their commitments or change their minds, so that’s why it is important to document any commitments and responsibilities that have been assigned to different people. You’ll find that this will help prevent confusion and miscommunication in the future. If possible, attach meeting summaries, files, and even signed agreements to the requirements to provide additional proof of decisions that have been made during this phase. It can also be quite helpful to attach graphs, workflow charts, or any other supportive documents that can provide additional information and make the requirement description clearer. You should also document activities that the client is committed to do, such as training, testing, and making their resources available. If you anticipate any misunderstanding along the way, document items that will not be included in the project but might be requested by the client in the future.

Step 5, Review, is about getting agreement from all the stakeholders and setting expectations from the different people involved. All stakeholders should get the written requirements definitions and provide feedback. This will give them a chance to verify that their wants and needs are properly addressed in the document. They’ll be able to see how all the components fit together, providing them with an overall picture. This stage can be done by conducting a meeting with all stakeholders and going over the requirements list, though that method works best if there are a fairly small number of participants in the process. For larger projects involving a number of teams and individuals, it’s better to distribute the documents to everybody and then collect feedback from each team. The teams can have their own internal meetings to discuss the document, then forward their feedback to the project manager.
The sixth step is Baselining, which means setting the requirements as the basis for the development process. Once approved, the requirements should be locked and used as the starting point of the project. If you perform similar types of projects, such as web site building, you can use the first requirements baseline as a template for future projects. Keep in mind that the locked document can be used as a legal tool in the future, in case there are any disagreements with the client regarding the project objective and results. The approved version should be distributed to all interested parties. All approval changes need to be made to this version and tracked using version control.

Verification and Validation is Step 7. Here you monitor the requirements through the project life cycle to make sure that the project is developed according to what they define. During this phase, the project manager ensures that each requirement is addressed and completed as planned. Use a test cases management system to run tests based on the requirements. It’s a very good idea to link the requirements with the tests and bugs that have been found during the testing phase. It’s best to define a priority level to each requirement and build the work plan that makes sure that all high level mandatory requirements are completed before the project is over. Throughout the project process, the project manager should track the completion level of each requirement to make sure that the project objectives are achieved.

The eighth and final step is Change Control. Most projects change after the baseline phase, so you need to control the changes and the affects that they have on other requirements, project phases, budget, and schedule.

The requirements phase obviously involves a lot of information gathering and tracking, but you’ll find that our program makes it a snap. Of course, your active participation in this process is key. We’re very excited to be showing you this new program, and we know you will love it. If you’re anything like me, you are really happy when a program comes along that raises your game. You’re already giving 100% and doing great things, but we’re going to show you how easy it is to get to the next level. Come on, let’s get started!

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.

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 Use Your New Elementool Account

Hi, it’s me Allison again.

I hope my last video helped you to setup your account. If you still have any questions, please contact

Today I’m going to show you how to use the account. It is so easy, even your grandmother can do it. This is done with the application section of Elementool, which includes the ‘Welcome Page’, ‘New Issue’, ‘View Issue’ and ‘Issue Report’.

The first thing you want to do is to submit new issues to the account. Once issues have been submitted, you can assign them to team members and run reports to track their progress.

To submit a new issue, click on the ‘New Issue’ button. Do you remember this form? We set it up in the previous video. Fill out the form and click on the Submit button to submit it to your account.

A few things you should know about the form:
• To assign an issue to someone on your team, select this person’s username in the ‘Assigned to’ field. If you want to send them an email with the issue details, check off the email checkbox next to this field.
• It is recommended to use a Status field to define the status of the issue. Your account comes with a default list of status values. The new issue is setup to have the status of Open Bug by default.
• Sometimes you need to attach files to an issue, such as screenshots, spreadsheets, etc. To do that, click on the Attach button below the form. Select the file you wish to attach, and upload it to the website.
• When you submit the new issue, the system will assign it a unique Issue Number. You will be able to use this number every time you want to reference this issue or view it.
Next is View Issue.

This is very simple. To view an issue, click on ‘View Issue’, submit the issue number and it will be displayed. You can now make changes to the issue and submit the update to the account.

A few things about the View Issue Form:
• The Remarks message board enables the users to submit remarks about this issue. It could be comments with further instructions, questions, explanation of how the problem was fixed, etc.
• The History Trail automatically tracks all the changes that have been made to the issue from the moment it has been submitted. It shows you the progress of this issue and helps you to identify a problem in its development.

Let’s run reports now:
Click on Issue Report.
You can customize the issue report by title, description, status, severity, assigned to, and much more. You can also customize the fields that appear in the report by clicking ‘customize report’.
The customize report option enables you to select the columns that are displayed on the report, the report’s sorting order and the query filters.

Next to the “customize report” tab is the “View type” option.
There are several view types: Normal, which displays the report on the page; Excel, so you can export the report to Excel; and Dynamic, to perform bulk field changes to the issues on the report itself – so you don’t need to update the issues one by one. Choosing the “print view” displays the report in a printer friendly fashion.
Quick Reports

If you frequently run the same report, you should add it to your quick reports. This feature allows you to run reports based on predefined criteria, rather than customizing your report each time. It is very simple to set-up.

Click on the ‘add report list’, and select the accounts and query fields you want present in the report. Customize the report based on your preferences, and click step 3. Select the report fields, such as the field list and report columns, and go to step 4. Lastly, name your quick report and click “save”.
Once you setup your quick reports, you can send the report results to people by email.
Last but not least is the Welcome Page
When you sign into your account, you see the “Welcome Screen” where your automated dashboard is displayed.

The Welcome page is fully customizable and enables you to add new items, change their location on the screen using drag n’ drop and have easy access to your quick reports
Clicking the ‘edit’ button on the dashboard box allows you to filter and customize the item based on your preferences. If you have several Elementool accounts, you can setup your dashboard to display your entire workflow. For example: you can display all your open issues, all the high priority tasks, and so on.

To add a new item to the Welcome Page, click on the ‘Add New Item’ button on the bottom of the page.
For example: Let’s say I want to see all the open issues that are assigned to me, and I would like to sort them by their priority.
• I click on ‘Add New Item’.
• In the Caption field I type: Open Issues Assigned to Me
• Display all ‘Assigned to’ and I select my username
• I click on Add Filter to add the status field as a filter.
• Select Status and Open bug.
• Group by: Priority
• Show as: Pie chart.
• Now I click on Save.
• You can now see the new item on my ‘Welcome Page’, which shows all open issues that are assigned to me.

This should get you started with your account.
I’ll show you more advanced and cool features in a few days.
Tomorrow I’ll send you an animated video that will explain the principles of Agile Development in three simple steps. I have a feeling you’ll love it.
Bye for now.

Website Facelift

In the next few weeks, we’re going to be making some design enhancements here at Elementool.com. But don’t worry, these changes will not have any affect on the way that you utilize our site.

During the redesign process, the application functionality will remain completely the same throughout the website, so you can continue using it without interruption. Here’s a sneak peek at the changes we have in store for Elementool.com.