Dumia – Requirements Analysis

Requirements analysis, also called requirements engineering, is the process of determining user expectations for a product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications. Requirements analysis is an important aspect of software development and is the main reason many software projects fail

Requirements analysis involves frequent communication with system users to determine specific feature expectations, resolution of conflict or ambiguity in requirements as demanded by the various users or groups of users, avoidance of feature creep and documentation of all aspects of the project development process from start to finish. Energy should be directed towards ensuring that the final system or product conforms to client needs rather than attempting to mold user expectations to fit the requirements.


Here are the requirements that we were given:

  1. The User should be able to browse a web application
  2. View Items on the Site
  3. Search for Items on the Site
  4. Add or Remove an item from the Shopping Cart
  5. Purchase Items using a Credit Card
  6. Kick off a fulfillment process
  7. Send Emails of Status to the User through each step in the Process

We will take each statement of the requirement and look at it in a detailed way. The goal of analyzing the requirements is to as best as possible visualize the solution that will solve the problem. Not HOW to go about building it. We are trying to envision a solution that best solves the problem (no matter how difficult we think it might be to build).

Domain Process and Data Modelling

Domain Modelling involves specifying the disparate Hardware and Software systems that need to interact to solve the problem. It may also contain process flow diagrams or data flow diagrams. It’s role is to give you and the members of your team a 1000ft view of the processes involved in the solution. That said, in the case of Dumia, Our Model is going to be quite simple


Dumia Business Process Flow

User Stories and Use Cases

A use case is a list of actions or event steps, typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system, to achieve a goal. The actor can be a human or other external system. A user story on the other hand a user story is a short and simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a <type of user>, I want <some goal> so that <some reason>.

So in short, a User Story contains multiple user stories. Applying this to our current requirements, we have the following User Stories and the corresponding Use cases

  • As an Anonymous User, I should be able to be to View Items that are in Stock
    • View Inventory (Available Products)
  • As an Anonymous User, I should be able to search for a specific Product
    • Find Product
  • As an Anonymous User, I should be able to Add or Remove an item from the Shopping Cart
    • View Cart Items
    • Add To Cart
    • Remove From Cart
    • Change Product Quantity in Cart
  • As an Anonymous User, I want to login so that I can gain access to Checkout
    • Login
  • As a Validated User, I want to Purchase Items using a Credit Card
    • Checkout Cart
    • Place Order
    • Pay for Order

User Interface Mocking

The role of mockups is to translate the Requirements into a Visual document that you can then give to the customer/business analyst/marketers and other members of your team  to make sure that you all understand the high level UI flow of the application. Note that the mockups must be able to satisfy the requirements without going into too much detail.

Mocks could be generated with a tool like Balsamiq or hand drawn. I would advice you start with hand drawn mocks so that that you can get a hang of it

For Dumia we have the following mocks

This slideshow requires JavaScript.


Collectively, these outputs of the Requirements Analysis is referred to as the Functional Specification. It best describes the functionality of the System. With these in place, We can move on to the next topic.. High Level Architecture


About Ody

Web Developer/Programmer and Hardcore Gamer. Mainly interested in the Web and Web Technologies

One thought on “Dumia – Requirements Analysis

  1. Pingback: Building Vamia | Tech Genius Blog

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s