CategoryBusiness Analysis

Many times when you’re eliciting requirements, you may be asked the question:

“We need to add a textbox on this page. How long will it take?”

Well… what’s your answer? How do you follow-up? To aid your requirements analysis journey, here’s a checklist that may help you predict the effort involved.

To start off, let’s take a simple task, such as “add a textbox on this page” and see what it could potentially involve. These requirements may apply to other web components of a web page.

Usability Requirements

Should the TextBox have a label? Above it? To the left of it?

Is it a required field?

Should it be pre-populated?

Does it require AJAX functionality? Autocomplete? Retrieved from a defined set of data?

Is the TextBox already conveyed somewhere else in the form? (I’ve had times where the stakeholder didn’t know that the field was already in there. )

Where on the form should it be? (This is particularly important if you’re dealing with a form wizard. )

Should the data be tracked via some analytics tool?

How many characters are allowed?

Inline validation or validation after form submission? Error message at the top of the form?

JavaScript validation or server-side validation? Both?

Should the TextBox have inline help?

How prominent should it be? Above the fold?

Business Requirements

Does this TextBox show up to all users or just Administrators? (Depending if there’s a user privilege hierarchy in a CMS. ) What user roles are allowed to see this?

Does the data gathered in this TextBox go against the business rules of another product in the company? (For example, the TextBox could be prompting for your social security number, while Finance’s policy strictly forbids it. The stakeholder you may be dealing with may not know this.)

Does this have to be conveyed through reporting?

Content Requirements

What should the microcopy be for the label, for the error message, or text in the TextBox if it’s prepopulated?

What’s the translation in another language? (Ideally, find a native speaker; Google Translator may not be sufficient. )

Engineering Requirements

Do you need to modify application code to fit this TextBox in? Which class/file? New method? New property?

Do you need to add a new database column for this TextBox? Is there a column that you can reuse? Which table should you put it in?

Does this database column need an index? A new table? Referential integrity?

What data type is it? Varchar? NVarchar? Text?

Does it need to be indexed via a Full-Text Search Engine?

Does the data from the TextBox need to be in the user’s session?

Will you need to create new language tokens in your resource file to add the copy for the TextBox and label? Can you repurpose (or should you) existing ones?

Do you need to use JavaScript framework to validate it? Use an existing JavaScript validation function or roll your own?

Use CSS3 for styling? HTML5?

Should any API’s/Web Services be updated because of this?

Because this is a new field that was not introduced at the birth of the system, what should existing records that now have this new field, be set by default? Null? Empty string? Default text value? ID?

Does it impact any unit tests? Create new ones?

Testing Requirements

Are the Usability, Content, and Business requirements (shown above) met?

How does it display in various web browsers?

How well does it do in usability testing?

Deployment Requirements

Are the changes for this TextBox small enough so that it can be rolled out with the normal scheduled builds?

If not, when can it be deployed?

Does the build script or process need to be modified to roll out these changes?

Project Resource Requirements

Do you have the human resources (developer, designer, usability tester, etc.) to work on this?

Do you have to update documents (requirements document, project plan, etc.)?

What is the priority and risk for this project?

How much will it cost?

That’s just a high-level summary. I didn’t even mention SEM/SEO, branding or design requirements (if applicable). I’m sure you can go to a QA engineer, a content strategist, a designer, or a DBA, and get a break-down of even more details. No doubt that you can dig deeper, but this should put you on the right track.

Here’s the requirements document template (the “Product Definition”) I created for use when I was a project manager. Feel free to use and change as needed. It serves as a basis for functional and non-functional requirements. To check out what other documents may be needed in a project, check out my Project Documents post.

In the past as a project manager, I came across various tools to management the never-ending lists of requirements. The following tools specialize in different key areas:

Requirements Gathering

Protopying of Products

Reporting

Use Case Modeling

Managing Actors & Resources

Collaborative Work Among Stakeholders

While Microsoft Project is best for timelines and allotting resources, its a major hassle getting it fine-grained as some of these tools. Also, it does not possess some of these major functions.

I bring this up because with all the major stakeholders and moving pieces in the auctions project, and because of the unique way that it has to be project-managed, we need more order in managing various resources and artifacts.

These are some of the items I’ve used in my projects. Not all items apply for all projects. Also, various items can happen simultaneously and could be maintained via various methods. Terminology may change depending on your organization.

Project Definition (PD) – Maintained via Microsoft Word

The biggest document of the lot. It includes project goals, target release, deliverables, requirements, use cases, business rules, glossary, and references other project/business documents.

Project Plan– Maintained via Microsoft Project

Timeline of the entire project. It includes, planning, approval, development, testing, deployment. The project manager receives the project plan from the vendor and may work with it as-is or may need to work together with the vendor to establish points.

Content Dictionary (CD)– Maintained via Microsoft Word

Content that will be on the user interface of applications / products. Two purposes:

It is formatted using a very primitive wire-frame layout. The wire-frame represents describes to the designer the priority of text and where on the page it should be. The design team then improves on the wire-frames to include usability then turn it into mock-ups of actual web pages.

Text is prepared in this document so it can easily be translated into multiple languages. This document is submitted to the translator and we get a document, with this same layout, but content translated.

Release Management (RM)– Maintained via Microsoft Word / Visio

A plan that lays out how the project is to be rolled out / released.

Quality Assurance– Maintained via Microsoft Word / Visio

A plan that lays out the strategy for quality assurance.

Site Map– Maintained via Microsoft Word / Visio

Visual layout representing new tree structure of pages that will be added to our current one.

A collection of other documents that are part of the project in which the vendor shall use to familiarize themselves on other parts of the company – business process for departments, other projects, policies, etc.

There are actually two parts to a shopping cart application. The first consists of the actual shopping cart (where the users search and buy items from) and the other is the administrative portion where tasks such as setting price, adding/deleting items to the database are done.

Shopping Cart

An Internet shopping cart actually consists of many subparts. These are the basics:

Catalog

Session Tracking

Search Engine

Security

Payment

Return/Exchanges

Catalog

A catalog is information about goods. Customers can browse the catalog (web pages) and see what there is in stock. Each good will most likely be composed of the name, picture, and price. Rather than assigning an item to each web page, the items can be generated dynamically from a database on to one page. Instead of listing all items on one page, a customer can browse through page by page. (All the items will be browsed page by page. For example, if there are 20 items, then it’s broken down into 4 pages. If there are 100 items, it will be broken down into 25 pages, with links that say Next/Back so they can go to the next page. In a catalog, it’s preferable that items be listed in categories.

Session Tracking

While a customer is browsing a catalog and looking for items, there has to be a way to keep track of what items he/she clicks on (so it gets sent to the customer’s shopping bag). This is done through session tracking. On check out, the check out process will tell them to register (fill in their information and pick a username and password) before checking out. The information, after they register, is saved in the database so they can login next time they enter the site and not have to reenter it again (all except credit card information).

Search Engine

This is closely related to the catalog. Rather than browsing and clicking links to find the item the customer wants, they can go to a search textbox and search for an item. This will be located on a visible spot on each page. After the customer submits the search, it will display the results like a catalog with Next/Back links.

Security

This is vital when processing credit cards and keeping customer information safe. Information submitted by the customer will be encrypted and stored in the database. Also, when submitting information so credit cards get processed, it will be submitted under an SSL secure connection. A logo can be shown by whomever company handles the SSL to make it shown that there is in fact security.

Payment

Directly connected with session tracking and security. Before checking out, customers will have to submit valid information about themselves. They will be sent to a form page under SSL where they must put valid information. After they submit, the data will be validated then sent off to a gateway where the funds will be sent to a merchant account. All done securely. An automatic e-mail will be sent to the user when this process is done.

Return/Exchanges
Done as secure as Payment. The customer will pick which item he wants to return, put all the necessary information from the invoice they received, and the return/exchange will be processed.

Administrative

The administrative portion consists of two basic subparts:

Content Management System (CMS)

Data Inventory

Content Management System (CMS)
There will be pages on the web site that have significant importance. For example, the home page and the catalog pages. These are pages that will constantly be changing. (The home page can contain items on sale, popular items, “just in,” etc. It might also be a good idea to include some of this home page information on the catalog pages because they are constantly browsed.)

Instead of changing the pages manually (opening up the page, changing the source code of each page), it will be faster and safer (changing the source code has to be done carefully so no errors occur) to do it through an administrative feature. You can go into an administrative panel, and just change that portion of the page that you want to update. There would never be a need to look at any code, just a click, type, and submit. Everything will be done through options. This is what a CMS does. Manages the content of pages.

Data Inventory

There will be a section under the administrative feature where company employees can insert/update/delete information from the database. This information can be customer, item, purchase information. They can also check out a queue of the items customers have purchased.

Shopping Cart Application Add-ons

Contingency Plan

A plan that’s executed if something fails or is performing poorly. For example, if the host goes down, there’s an error in the application, or there’s a hacker break-in.

Automation

Schedule content through the content manager. Can assign by date when something will be on sale, for example. When the date comes, it will display the new information on the page automatically.

Forum/Message Board

This will create an online community.

Chat

Where people can interact in real time.

Rating

Each item can have its own rating. For example, 1 out of 5 stars.

Reviews
Users can critique each item. Contains language filter.

Reports

Stats can be generated according to customer’s habits. What they click on, what the buy, etc. Reports can be generated according to this information. As an option, automated actions can be taken upon reporting information. For example, if a customer has bought purely shoes in the past from the site, then show shoes on the home page.

Advanced Search

Search not only by item name, but by price range, date range, and any other related information.

Data Export

Export information from the database as text files, XML, Access and Excel.

Mailing Lists

Send customers e-mails with news on prices, offers, new items, etc.

Portals

A page that contains links and other related information about other sites.

Gift Certificate

Gift Certificates can be bought online so it can be used in-store or online.

Site Map

Will contain a list or a map of all the sections and pages of the web site for quick navigation.