Requirements Engineering

From Business to Functional Requirements

Today almost every product is an exercise in software development. The first step in the project is requirements analysis. Requirements analysis is concerned with what the system (whether it be a "traditional" application or a Web appliction) needs to do. This involves examining the requirements of the business itself, the users of the application against the backdrop of cost and engineering constraints such as throughput and response time.

Business Requirements

• Business Requirements analysis - Describe he business and its it’s customers, suppliers and users problems issues and expectations. This is essential when developing a new application but also crucial when you’re making significant changes to an application. “Why” do you want to develop the software and “How much” is it going to cost? Is there a ROI (return on investment). Can your team develop and implement the product?
• P.I.E – Problems Issues and Expectations - Describe current problems and put the issues and expectations that users have in the current environment into separate categories. An expectation may be crucial to success of the project or it may be a “user satisfaction” feature that can be postponed to Revision 9.5
• Causes and Consequences - Discuss causes of current system problems and their consequences. You will discover that a problem’s result is often a problem in it’s own right. You need to drill down to the root cause of the problem peeling away the symptoms.
• Target system tasks - Discuss and observe users as they work with a similar product or software application. Remember that the important things are (a) how easy it is to install a product (b) how quickly does it work and c) how intuitive is the UI. This is particularly relevant to Web-based applications, where the user experience will make or break the application.
• System Design Alternatives Analysis - Very few systems are new. In alternatives analysis you will consider the strengths and weaknesses of existing approaches including not doing the project at all.

Software / hardware requirements

A business requirements analysis is not enough to ensure that a system meets the real needs of its users or that it will ever succeed in the real world as a product. In fact, reducing a system specification to a set of required functions, without regard to how the functions are used or how they will be implemented in real hardware/software by real people is a guarantee for failure . The design of a new system or major change will usually involve the following steps:

• Task Decomposition - Business requirements are broken down into software and hardware modules and features.
• User stories- A “user story” corresponds to a feature of a system module. Stories are small, typically limited by an estimate to implement the software for a story by one programmer working for one week. The user story needs to stay in sync with the business requirements – and stay away from gold-plating.
• Data Modelling - Data modelling describes required data elements in the proposed system and the relationships between the data elements. Done in parallel to developing the “user stories” and ensures that the data needed to do the job is on the model.
• User Interface Design - The user interface needs to be considered at an early stage in the development cycle. Functional requirements are combined with the knowledge gathered about users and contexts of use to provide the most appropriate methods of interaction.
• Rapid Prototyping - Develop a little piece of the system with stub routines and a skeletal UI. Prototyping allows design concepts to be tested, with resulting feedback incorporated into an iterative process. Early prototypes may be purely paper-based (low fidelity) or using a Web prototype with HTML or PHP