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:
- The User should be able to browse a web application
- View Items on the Site
- Search for Items on the Site
- Add or Remove an item from the Shopping Cart
- Purchase Items using a Credit Card
- Kick off a fulfillment process
- 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 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
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
- As a Validated User, I want to Purchase Items using a Credit Card
- Checkout Cart
- Place Order
- Pay for Order
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
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