If you haven’t already, check out the first four posts in this series: It’s easier than you think, lets build a web app

Can I get fries with that?

Once you have a decent idea of the goals and objectives for a project, it’s time to move onto the requirements. Whether written in a document or on post-it notes, requirements act as your project check-list. Once the requirements are all ticked off, you should have achieved what you set out to accomplish.

Requirements are an interesting beast. If you don’t focus on the right requirements, it can really impact on where the project ends up.

Requirements often follow one of the following methods:

Example 1 – System focused requirements:

• The system must allow the creation of a new customer record.

Example 2 – User Stories:

• As an App-Makers employee, I want to record interactions with a customer, so that I can see the history of interactions over time.

Example 3 – Behaviour driven tests (Jasmine style):

 describe("As an App-Makers employee, I want to create a customer record", function() {
      it("The Customer must have a name", function() {
           var name = customer.name;
           expect(name).not.toBeNull();
      });
});

The theory is that behaviour driven tests can be written up front, and then used for unit testing – reducing testing time down the track. The success of this approach really depends on the amount of detail that is known about the solution when the requirements are written. As part of the Agile process, a unit of work (work-unit) may be known in quite a lot of detail, or may be quite vague.

Behaviour driven tests are also a great way to make sure that the requirements aren’t forgotten about as the project progresses (yes, this actually does happen). It also means that we may not need to have a separate document for business rules, and for mapping requirements to business rules for traceability. This traceability is traditionally done using a matrix to trace requirements to rules and tests.

There’s no better way to show progress than when you can easily show how many tests are passing at any point in time.

Let’s draw out our App-Makers example a little further and bring our objectives back into the mix. This is where we bring all of the key information together, an overview of everything that we know about App-Makers, and the findings from our data flow diagrams and process flows.

Business Requirements

Lets have a look at our business requirements written using a combination of the methods mentioned above, some of the detailed requirements below have been written using Jasmine – Behaviour driven tests (BDT). If you’re not familiar with JavaScript or Jasmine, it’s okay, just look at the bits in blue.

1. Identify key characteristics of the current customers that use App-Makers services.

   1.  it("The Customer should have an Address", function() {
           var suburb = customer.suburb;
           var country = customer.country;
           expect(suburb).not.toBeNull();
           expect(country).not.toBeNull();
      });
      

   2.  it("The Customer should have an Industry", function() {
           var industry = customer.industry;
           expect(industry).not.toBeNull();
      });
      

2. Identify the current customer segments who don’t currently use App-Makers, but who would be good candidates.
3. Generate a report based on industry and customer location potential
4. A record of each customer

   1.  describe("As an App-Makers employee, I want to create a customer record",
      function() {});
      

   2.  describe("As an App-Makers employee, I want to update a customer record",
      function() {});
      

   3.  describe("As an App-Makers employee, I want to retrieve a detailed customer record",
      function() {});
      

   4.  describe("As an App-Makers employee, I want to retrieve a list of customer records",
      function() {});
      

   5.  it("The Customer must have a first name", function() {
           var firstName = customer.firstName;
           expect(firstName).not.toBeNull();
      });
      

   6.  it("The Customer must have a surname name", function() {
           var surname = customer.surname;
           expect(surname).not.toBeNull();
      });
      

   7.  it("The Customer must have an email address", function() {
           var email = customer.email;
           expect(email).not.toBeNull();
      });
      

   8.  describe("Customer email validation", function() {
           it("should validate [email protected]",function(){
                var result = is_valid("[email protected]");
                expect(result).toBe(true);
           });
      
           it("should not validate someone@somewhere",function(){
                var result = is_valid("someone@somewhere");
                expect(result).not.toBe(true);
           });
      });
      
      is_valid = function(email){
           var reg_expr = /^([A-Za-z0-9_\-\.])+\@([A-Za-z0-9_\-\.])+\.([A-Za-z]{2,4})$/;
           return reg_expr.test(email);
      };
      

   9.  it("The Customer should have a phone number", function() {
           var phone = customer.phone;
           expect(phone).not.toBeNull();
      });
      

5. An indication of which customers have approached App-Makers from a referral

   1.  it("The Customer should have a referred indicator", function() {
           var referred = customer.referred;
           expect(referred).not.toBeNull();
      });
      

6. The channel that new customers are using to contact App-Makers

   1.  it("The Customer should have a channel indicator", function() {
           var channel = customer.channel;
           expect(channel).not.toBeNull();
      });
      

7. An indication of which customers have made at least one referral

   1.  it("The Customer should have a referral indicator", function() {
           var referral = customer.referral;
           expect(referral).not.toBeNull();
      });
      

8. A facility to identify and contact those customers whom have made referrals.

   1.  describe("As an App-Makers employee,
      I want to retrieve a list of customers whom have made referrals",
      function() {});
      

   2.  describe("As an App-Makers employee,
      I want to send an email to a list of customers whom have made referrals",
      function() {});
      

   3.  describe("As an App-Makers employee,
      I want to set up email templates to send out to groups of customers",
      function() {});
      

9. Solution Specific Requirements
   1. A user must be registered to access the system and the information contained within it.
   2. A user must be able to log-into the system from a mobile device, tablet, and laptop computer.
   3. When an attempted login fails, the user must be prompted to try again.

Analysing the requirements:

When considering the requirements in detail:

• We would remove the necessity for customers to have a first name. This is because in some countries, single names are quite common, thus the concept of a ‘Mononymous person’. Some people only have single names – and this isn’t just limited to Madonna or Beyonce.
• We would look at the questions that pop out from the requirements, for example, 7 – is a requirement to have a referral indicator. However, it’s quite likely that a customer who makes a referral may do it more than once.
• We could also add non-functional requirements here, such as security and performance.

This type of analysis of the requirements can save a lot of time and effort down the track.

Now that we have a set of requirements, we can reconsider Feasibility and Fit Gap. For our purposes, we’ll assume that we’ll be building a custom web app using HTML, CSS and JavaScript – using the MEAN stack (MongoDB, Express, Angular.js, Node.js). Now, we can progress into the design phase!

Quick question: if the cost of implementing a technical solution is greater than the cost of not having the solution, should you continue?

We’ll explore the design process further in the next post.

Use cases and storyboards – Part 5

Behaviour Driven Requirements – Part 4