Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. It is an early stage in the more general activity of requirements engineering which encompasses all activities concerned with eliciting, analyzing, documenting, validating and managing software or system requirements.

Requirements analysis is critical to the success of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Conceptually, requirements analysis includes three types of activities:

• Eliciting requirements: the task of identifying the various types of requirements from various sources including project documentation, (e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering.
• Analyzing requirements: determining whether the stated requirements are clear, complete, consistent and unambiguous, and resolving any apparent conflicts.
• Recording requirements: Requirements may be documented in various forms, usually including a summary list and may include natural-language documents, use cases, user stories, or process specifications.

Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. These may include the development of scenarios (represented as user stories in agile methods), the identification of use cases, the use of workplace observation or ethnography, holding interviews, or focus groups (more aptly named in this context as requirements workshops, or requirements review sessions) and creating requirements lists. Prototyping may be used to develop an example system that can be demonstrated to stakeholders. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced.

Stakeholder identification

See Stakeholder analysis for a discussion of business uses. Stakeholders (SH) are people or organizations (legal entities such as companies, standards bodies) that have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:

• anyone who operates the system (normal and maintenance operators)
• anyone who benefits from the system (functional, political, financial and social beneficiaries)
• anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing and sometimes sales act as surrogate consumers (mass-market customers) to guide development of the product
• organizations which regulate aspects of the system (financial, safety, and other regulators)
• people or organizations opposed to the system (negative stakeholders; see also Misuse case)
• organizations responsible for systems which interface with the system under design
• those organizations who integrate horizontally with the organization for whom the analyst is designing the system

Stakeholder interviews

Stakeholder interviews are a common technique used in requirement analysis. Though they are generally idiosyncratic in nature and focused upon the perspectives and perceived needs of the stakeholder, often this perspective deficiency has the general advantage of obtaining a much richer understanding of the stakeholder's unique business processes, decision-relevant business rules, and perceived needs. Consequently this technique can serve as a means of obtaining the highly focused knowledge that is often not elicited in Joint Requirements Development sessions, where the stakeholder's attention is compelled to assume a more cross-functional context, and the desire to avoid controversy may limit the stakeholders willingness to contribute. Moreover, the in-person nature of the interviews provides a more relaxed environment where lines of thought may be explored at length.

Joint Requirements Development (JRD) Sessions

Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained facilitator, wherein stakeholders participate in discussions to elicit requirements, analyze their details and uncover cross-functional implications. A dedicated scribe and Business Analyst should be present to document the discussion. Utilizing the skills of a trained facilitator to guide the discussion frees the Business Analyst to focus on the requirements definition process.

JRD Sessions are analogous to Joint Application Design Sessions. In the former, the sessions elicit requirements that guide design, whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements.

Contract-style requirement lists

One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages long.

An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favour in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims; but they are still seen to this day.

Strengths

• Provides a checklist of requirements.
• Provide a contract between the project sponsor(s) and developers.
• For a large system can provide a high level description.

Weaknesses

• Such lists can run to hundreds of pages. They are not intended to serve as a reader-friendly description of the desired application.
• Such requirements lists abstract all the requirements and so there is little context. The Business Analyst may include context for requirements in accompanying design documentation.
  • This abstraction is not intended to describe how the requirements fit or work together.
  • The list may not reflect relationships and dependencies between requirements. While a list does make it easy to prioritize each individual item, removing one item out of context can render an entire use case or business requirement useless.
  • The list doesn't supplant the need to review requirements carefully with stakeholders in order to gain a better shared understanding of the implications for the design of the desired system / application.
• Simply creating a list does not guarantee its completeness. The Business Analyst must make a good faith effort to discover and collect a substantially comprehensive list, and rely on stakeholders to point out missing requirements.
• These lists can create a false sense of mutual understanding between the stakeholders and developers; Business Analysts are critical to the translation process.
• It is almost impossible to uncover all the functional requirements before the process of development and testing begins. If these lists are treated as an immutable contract, then requirements that emerge in the Development process may generate a controversial change request.

Alternative to requirement lists

As an alternative to the requirement lists Agile Software Development uses User stories to suggest requirement in every day language.

Measurable goals

Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.

Prototypes

Prototypes are Mockups of an application, allowing users to visualize an application that has not yet been constructed. Prototypes help people get an idea of what the system will look like, and make it easier for projects to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.

Prototypes can be flat diagrams (often referred to as wireframes) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion as to whether the prototype represents the final visual look and feel of the application.

Use cases

A use case is a structure for documenting the functional requirements for a system, usually involving software, whether that is new or being changed. Each use case provides a set of scenarios that convey how the system should interact with a human user or another system, to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end-user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.

Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of the ways in which users are intended to work with the software or system. Use cases should not describe internal workings of the system, nor should they explain how that system will be implemented. Instead, they show the steps needed to perform a task.

The requirement gathering part is partially done in problem analysis phase. The document created in first step would help you to get started in this page. This is tough phase and is very critical to the success of your data warehouse development. Clear requirement and thorough analysis is must for success of any data warehouse project.

1. Prepare the questionnaire for the future users of the new Data Warehouse and Business Intelligence Solution.
2. Ask very specific questions rather than high level.
3. Find out the Data Sources for the Data Warehouse data.
3. Check if you can use existing system if any as a data source for the Data Warehouse.
4. Find out the possible data to be inserted every day in the Data Warehouse.
5. Get a list of reports that is supposed to come out of the new data warehouse.
6. Understand the existing Business and terminologies.
7. Find out if client is ready for commercial BO tools or Open Source tools.

Requirement analysis and gathering is a bit tough as client might no be clear with his/her requirement. It’s your expertise in the design process and prior experience which help you to analyze the requirement and put it on paper. Once everything is clear make sure you get a sign off from the client on the requirement.

Problem definition and analysis is the important phase of any development project. A good problem analysis and definition leads to a good solution.
While defining problems asking questions is a good practice to go to deep into problems this help further while designing approaches to solve the problem.

Following questions might help you get started on this stage of Data warehouse design.

1. Is there any existing reporting system which is in use?
2. What are the main problem areas of existing system?
3. Interview the existing users to understand the problems and their expectation from future Business Intelligence Solution.

Document all your findings and now sit and analyze the problem. If possible try to put your problem in diagrammatic way and create a storyboard.

This is the actual start of your Data Warehouse project. Following things needs to executed in this step.

1. Design a data model based on requirement analysis. It could be star schema or snowflake schema based on requirement. Data modeling consist of following three parts.
a. Conceptual data model
b. Logical data model
c. Physical data model
2. Document in the data model design process including all possible details.
3. Get it reviewed and cross check the data model with reporting needs and your technical team.
5. Design a ETL process. ETL can be done using home grown tool or commercial tools. Having commercial tool speed up the process and also make is easy to maintain as skill set and support is available easily.
6. Create a sample data for the data warehouse and ETL. this could be a snap shot of the OLTP data.
5. Create a Unit testing plan and test ETL and data model for every new addition and change.
6. Try creating sample reports on top of data warehouse to test it.

Many times this step can be skipped if Organization is ready to implement the data warehouse and clear about why they need a data warehouse. Following points can help you to successful execution of this step.

1. Get the most talented and experience people in this step as there past experience in data warehouse design will help a lot to design a prototype fast.
2. Make sure you implement the prototype in a manner which can be further reused in actual development.
3. Document the prototype
5. Use ready to use tools instead of using any high level language to create a tool to use in prototype. This will help to save time.
6. Create sample Data warehouse with sample data in it which can feed 2-3 reports.
7. Present the prototype to end users to get a feel of proposed solution.
8. Once done, Get sign off on prototype.

Remember prototype is a very small part of your actual development project. It needs to done fast. If Business Users like your prototype success of Data warehouse project is very near.

-BIDW