Business Analyst-External link

Business Analyst role and responsibilities

Requirement Specification

The software requirements specification is a document that lists out stakeholders’ needs and communicates these to the technical community that will design and build the system. The challenge of a well-written requirements specification is to clearly communicate to both these groups and all the sub-groups within.

To overcome this, Requirements Specifications may be documented separately as

User Requirements - written in clear, precise language with plain text and use cases, for the benefit of the customer and end-user
System Requirements - expressed as a programming or mathematical model, addressing the Application Development Team and QA and Testing Team.

Requirements Specification serves as a starting point for software, hardware and database design. It describes the function (Functional and Non-Functional specifications) of the system, performance of the system and the operational and user-interface constraints that will govern system development.

Requirement Management

Requirements Management is the comprehensive process that includes all aspects of software requirements analysis and additionally ensures verification, validation and traceability of requirements. Effective requirements management practices guarantee that all system requirements are stated unambiguously, that omissions and errors are corrected and that evolving specifications can be incorporated later in the project lifecycle.

The purposes of Analysis & Design are:

1. To transform the requirements into a design of the system to-be.
2. To evolve a robust architecture for the system.
3. To adapt the design to match the implementation environment, designing it for performance.

An analysis mechanism represents a pattern that constitutes a common solution to a common problem. They may show patterns of structure, patterns of behavior, or both. They are used during analysis to reduce the complexity of analysis, and to improve its consistency by providing designers with a shorthand representation for complex behavior.
Mechanisms allow the analysis effort to focus on translating the functional requirements into software concepts without bogging-down in the specification of relatively complex behavior needed to support the functionality but not central to it.

The process of Requirement Analysis

Once all the stakeholder requirements have been gathered, a structured analysis of these can be done after modeling the requirements. Some of the Software Requirements Analysis techniques used are requirements animation, automated reasoning, knowledge-based critiquing, consistency checking, analogical and case-based reasoning.

It is always a next to impracticable job to get a) faultless requirements b) to do perfect analysis on the requirements c) lastly to convert them faultlessly into design or take to next SDLC level. In fact irrespective of metrics we use to measure requirements and take it to next level we should always keep in mind that the person who is gathering them and who is giving them both are human beings and lot of noise get introduced while in their communication. Hence requirements are bound to misled from their actual meaning to the understanding of gatherer.
This makes almost 30% of requirements either completely useless or almost impossible to convert them into a software product. Now should be done minimize such a huge gap. Almost all of the requirements should be supported by facts and data. Always remember the difference between stakeholders and end users, end users will be using your solutions so always double check any gathered requirement with them.

Requirement Analysis

Analysis

• Software engineering task bridging the gap between system requirements engineering and software design.
  
• Provides software designer with a model of: 
  

- system information
- function
- behavior

• Model can be translated to data, architectural, and component-level designs.
  
• Expect to do a little bit of design during analysis and a little bit of analysis during design.

Analysis Objectives

• Identify customer’s needs.
  
• Evaluate system for feasibility.
  
• Perform economic and technical analysis.
  
• Allocate functions to system elements.
  
• Establish schedule and constraints.
  
• Create system definitions.
  

Benefits of JAD sessions

If the above guidelines are followed closely, chances are, the JAD will be successful. A successful JAD session should provide these benefits:

Reduced system development time. In JAD, information can be obtained and validated in a shorter time frame by involving all participants (or at least a representative set of participants) who have a stake in the outcome of the session. JAD eliminates process delays and has been shown to reduce application development time between 20% to 50%.

Improved system quality and productivity. Much of the system’s quality depends on the requirements gathered. JAD involves users in the development life cycle, lets users define their requirements, thus ensures that the system developed satisfies the actual activities of the business. JAD is quoted the best method for collecting requirements from the users, customers, or customer advocates.

Reduced system cost. Much of the system development cost is in terms of man-hours of both system developers and business users involved. Reduced development time reduces the labor cost for developers, as well as users. Important process like requirement gathering requires the involvement and commitment of business area experts. The cost of taking them away from their daily operation is very high. JAD can reduce the involvement time of these business experts and hence reduce the cost further. Cost is also reduced by catching errors, misunderstandings and mistakes early in the development phrase. Studies have found that a majority of system errors result from early analysis errors, and the earlier these errors are corrected, the much less they will cost. The JAD sessions let designers and users work together in the very early of the development cycle, defining the scope, requirements of projects, resolving conflicts among different user groups. It put much efforts early in the life cycle in order to improve the quality and increase productivity and to reduce cost.

Enhanced communication and relationship between business end-users and IT personnel.

Cultivate ownership, easier acceptance (buy-in) and stronger commitment by users. The involvement of business end-users is no longer on advisory or consultation spectrum. It is the participation and contribution in the project development life-cycle. The more users contribute to the system, the easier for them to accept it and commit to it.

Reduced function creep. It was cited by Gary Anthes to be one of the best ways to reduce function creep, most of which results from poor initial requirements.

Enhanced education for participants and observers. By participating in JAD and be the medium between other users and IT, the business end-users will be kept fully informed about the progress of the system development.

Under the trends of emphasis on group work, quality and productivity, and attention shift from technology to business, the most frequently cited success indicators for applications were: timely delivery, achievement of business objectives, and building positive communications and relationships with customers. In the meantime, people are expecting higher productivity. Conducted properly, JAD can improvement all of these areas, and contribute greatly to development of a successful system.

http://www.umsl.edu

Guidelines for Successful JAD

Researchers and practitioners not only recognize a similar list of JAD components, their lists of guidelines for successful JAD sessions have many commonality too. Not all JADs are successful, some are even disastrous.[23] These guidelines are based on research results and personal experiences and are given to avoid failures. They represent the critical success factors and they are to be followed carefully. These guidelines are summarized below:

• Use experienced and skilled facilitators
  
• Get Executive Sponsor’s commitment and support
  
• Get the right people to participate, predefine their roles and responsibilities
  
• Set clear defined, well understood and obtainable goals or objectives
  
• Plan detailed agenda and stick with it
  
• Define deliverables clearly in advance
  
• Keep Technical Jargon to a Minimum
  
• Produce Final Document Quickly
  

After all, the most important thing for a project is to use a skilled facilitator. The most important thing for a facilitator is to do a good preparation. That’s why in Jane Wood and Denise Silver’s second edition Joint Application Development, three out of five defined phases of JAD sessions are pre-session activities. These five phases are:

1. JAD project definition
   
2. Research on user requirement
   
3. Preparation for the JAD session
   
4. Conducting and facilitating the JAD session itself, and
5. Predicting and obtaining approval of the final document that incorporates all decisions made.

If these 5 phrases are all carried out well, the JAD will be successful. Not one of them should be omitted.

http://www.umsl.edu

The JAD session

Despite the different definitions and manes for JAD, there is one thing common among them -- the facilitated session. JAD is either defined as such a session itself, or contains such a session. The basic components of a JAD session is listed below

Executive Sponsor: The executive who charters the project, the system owner. They must be high enough in the organization to be able to make decisions and provide the necessary resources and support for the project. They might attend the opening and closing session.

PROJECT LEADER/manager: Generally the leader of the application development team answers questions about the project regarding scope, time, coordination issues and resources. They may contribute to the sessions as long as they do not inhibit the participants.

FACILITATOR/SESSION LEADER: Chairs the meeting and directs traffic by keeping the group on the meeting agenda. The facilitator is responsible for identifying those issues that can be solved as part of the meeting and those which need to be assigned at the end of the meeting for follow-up investigation and resolution. The facilitator serves the participants and does not contribute information to the meeting.

SCRIBE/MODELER/Recorder/Documentation Expert: Records and publish the proceedings of the meeting and does not contribute information to the meeting.

PARTICIPANTS: Customers in the business area directly or indirectly being affected by this project, who are experts in their field and can make decisions about their work. They are the source of the input to the session.

OBSERVERS: Generally members of the application development team assigned to the project. They are to sit behind the participants and are to silently observe the proceedings.

Besides people listed above, each JAD session has well-defined objectives, detailed agenda and guidelines, visual aids, and a final document containing all the decisions made by the group.

http://www.umsl.edu

Gathering requirements- One on One interview

One on One interviews are the most common methods of interviewing. The technique involves having an interviewee and interviewer, there can be some variations when there is scribe present to document the proceedings. ( normally the business analyst takes down the minutes of the meeting).

The following process will help the interview proceed efficiently and effectively and will help you gather requirements in the shortest time. 

1. Prepare ahead of time: preparation for an interview involves reviewing all prior relevant deliverables, such as project definition and other business planning documents. You should also look into any historical data that is available to see if similar analysis has been performed in the past on a prior project. The interviewer should also take initiative in preparing, scheduling and also reserving the meeting space. Choose an appropriate time to schedule a meeting. Do not schedule meeting at the end of the day. If arranging for a meeting during lunch hours provide lunch, if the meeting goes on for a long time.

2. Conduct the Interview: When the interview begins you should put your questioning and listening skills to good use. Once the interview begins, the interviewer should be flexible to the discussion and lead the discussion where it needs to go. 

   - Answer upfront questions: After the purpose of the project is explained, the interviewee might ask questions about the project, interviewee's role and the purpose of the project, take some time to answer these kinds of questions, and also give the interviewee a chance to ask some questions. 

   - Consider the use of two interviewers: This process might be considered when some one provides large amount of detailed information or this method can be substituted with a tape recorder (prior permission of the interviewee is required to record their interviews).

   - Confirm the time period of the interview:  This helps on focussing on the discussion and helps everyone in providing the requirements in the concise time period.

   - Follow the interviewee's method of sequencing the material

 Ask you questions and listen to their responses, prepare to document the discussion accordingly. 

3. Documentation: After the interview is complete document the discussion and send it back to the interviewee for review. The purpose of the review is to validate that the interviewer has captured the information correctly. 

Communication-Asking questions and listening

The important part of elicitation is the art of communication. Elicitation is dependent upon the successful communication between the client and the analyst. The client must strive to communicate how he or she works today, the changes that need to be made, why the changes are important and the potential consequences associated with the changes made. This information will be turned into requirements by the analyst. The analyst must have strong verbal skills and understand the right questions to ask.  The analyst must also have active listening skills to ensure that he or she understands the intentions of the client. 

Who Is Using the Rational Unified Process?

More than a thousand companies were using the Rational Unified Process at the end of 2000. They use it in various application domains, for both large and small projects. This shows the versatility and wide applicability of the Rational Unified Process. Here are examples of the various industry sectors around the world that use it:

• Telecommunications
• Transportation, aerospace, defense
• Manufacturing
• Financial services
• Systems integrators

More than 50% of these users are either using the Rational Unified Process for e-business or planning to do so in the near future. This is a sign of change in our industry: as the time-to-market pressure increases, as well as the demand for quality, companies are looking at learning from others' experience, and are ready to adopt proven best practices. The way these organizations use the Rational Unified Process also varies greatly: some use it very formally; they have evolved their own company process from the Rational Unified Process, which they follow with great care. Other organizations have a more informal usage, taking the Rational Unified Process as a repository of advice, templates, and guidance that they use as they go along -- as a sort of "electronic coach" on software engineering.

6. Control Changes to Software

Particularly in an iterative development, many work products are often modified. By allowing flexibility in the planning and execution of the development and by allowing the requirements to evolve, iterative development emphasizes the vital issues of keeping track of changes and ensuring that everything and everyone is in sync. Focused closely on the needs of the development organization, change management is a systematic approach to managing changes in requirements, design, and implementation. It also covers the important activities of keeping track of defects, misunderstandings, and project commitments as well as associating these activities with specific artifacts and releases. Change management is tied to configuration management and measurements.

5. Continuously Verify Quality

Often people ask why there is no worker in charge of quality in the Rational Unified Process. The answer is that quality is not added to a product by a few people. Instead, quality is the responsibility of every member of the development organization. In software development, our concern about quality is focused on two areas: product quality and process quality.

• Product quality -- The quality of the principal product being produced (the software or system) and all the elements it comprises (for example, components, subsystems, architecture, and so on).
• Process quality -- The degree to which an acceptable process (including measurements and criteria for quality) was implemented and adhered to during the manufacturing of the product.

Additionally, process quality is concerned with the quality of the artifacts (such as iteration plans, test plans, use-case realizations,design model, and so on) produced in support of the principal product.

4.Visually Model software

Models are simplifications of reality; they help us to understand and shape both a problem and its solution, and to comprehend large, complex systems that we could not otherwise understand as a whole. A large part of the Rational Unified Process is about developing and maintaining models of the system under development.

The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. It gives you a standard means of writing the system's blueprints, covering conceptual items such as business processes and system functions, as well as concrete items such as classes written in a specific programming language, database schemas, and reusable software components. While it provides the vocabulary to express various models, the UML does not tell you how to develop software. That is why Rational developed the Rational Unified Process, a guide to the effective use of the UML for modeling. It describes the models you need, why you need them, and how to construct them. RUP2000 uses UML version 1.4.

3. Use Component-Based Architecture

Use cases drive the Rational Unified Process throughout the entire lifecycle, but design activities center on architecture -- either system architecture or, for software-intensive systems, software architecture. The main focus of early iterations is to produce and validate a software architecture. In the initial development cycle, this takes the form of an executable architectural prototype that gradually evolves, through subsequent iterations, into the final system.

The Rational Unified Process provides a methodical, systematic way to design, develop, and validate an architecture. It offers templates for describing an architecture based on the concept of multiple architectural views. It provides for the capture of architectural style, design rules, and constraints. The design process component contains specific activities aimed at identifying architectural constraints and architecturally significant elements, as well as guidelines on how to make architectural choices. The management process shows how planning the early iterations takes into account the design of an architecture and the resolution of major technical risks.

A component can be defined as a nontrivial piece of software: a module, package, or subsystem that fulfills a clear function, has a clear boundary, and can be integrated into a well-defined architecture. It is the physical realization of an abstraction in your design. Component-based development can proceed in several ways:

• In defining a modular architecture, you identify, isolate, design, develop, and test well-formed components. These components can be individually tested and gradually integrated to form the whole system.
•Furthermore, some of these components can be developed to be reusable, especially components that provide solutions to a wide range of common problems. Reusable components are typically larger than mere collections of utilities or class libraries. They form the basis of reuse within an organization, increasing overall software productivity and quality.
• More recently, the advent of commercially successful infrastructures supporting the concept of software components -- such as Common Object Request Broker Architecture (CORBA), the Internet, ActiveX, and JavaBeans -- has launched a whole industry of off-the-shelf components for various domains, allowing developers to buy and integrate components rather than develop them in-house. The first point above exploits the old concepts of modularity and encapsulation, bringing the concepts underlying object-oriented technology a step further. The final two points shift software development from programming software (one line at a time) to composing software (by assembling components).

The Rational Unified Process supports component-based development in several ways.

• The iterative approach allows developers to progressively identify components and decide which ones to develop, which ones to reuse, and which ones to buy.
• The focus on software architecture allows you to articulate the structure. The architecture enumerates the components and the ways they integrate, as well as the fundamental mechanisms and patterns by which they interact.
• Concepts such as packages, subsystems, and layers are used during analysis and design to organize components and specify interfaces.
• Testing is organized around single components first and then is gradually expanded to include larger sets of integrated components.

2. Manage Requirements

Requirements management is a systematic approach to eliciting, organizing, communicating, and managing the changing requirements of a software-intensive system or application.

The benefits of effective requirements management are numerous:

• Better control of complex projects. This includes greater understanding of the intended system behavior as well as prevention of requirements creep.
• Improved software quality and customer satisfaction. The fundamental measure of quality is whether a system does what it is supposed to do. With the Rational Unified Process, this can be more easily assessed because all stakeholders have a common understanding of what must be built and tested.
• Reduced project costs and delays. Fixing errors in requirements is very expensive. With effective requirements management, you can decrease these errors early in the development, thereby cutting project costs and preventing delays.
• Improved team communication. Requirements management facilitates the involvement of users early in the process, helping to ensure that the application meets their needs. Well-managed requirements build a common understanding of the project needs and commitments among the stakeholders: users, customers, management, designers, and testers. It is often difficult to look at a traditional object-oriented system model and tell how the system does what it is supposed to do. This difficulty stems from the lack of a consistent, visible thread through the system when it performs certain tasks. In the Rational Unified Process, use cases provide that thread by defining the behavior performed by a system.

Use cases are not required in object orientation, nor are they a compulsory vehicle in the Rational Unified Process. Where they are appropriate, however, they provide an important link between system requirements and other development artifacts, such as design and tests. Other object-oriented methods provide use-case-like representation but use different names for it, such as scenarios or threads.

The Rational Unified Process is a use-case-driven approach, which means that the use cases defined for the system can serve as the foundation for the rest of the development process. Use cases used for capturing requirements play a major role in several of the process workflows, especially design, test, user-interface design, and project management. They are also critical to business modeling.

1. Develop Software Iteratively

Most software teams still use a waterfall process for development projects, completing in strict sequence the phases of requirement analysis, design, implementation/integration, and test. This inefficient approach idles key team members for extended periods and defers testing until the end of the project lifecycle, when problems tend to be tough and expensive to
resolve, and pose a serious threat to release deadlines. By contrast, RUP represents an iterative approach that is superior for a number of reasons:

• It lets you take into account changing requirements. The truth is that requirements usually change. Requirements change and "requirements creep" -- the addition of requirements that are unnecessary and/or not customer-driven as a project progresses --have always been primary sources of project trouble, leading to late delivery, missed schedules, dissatisfied customers, and frustrated developers.
• Integration is not one "big bang" at the end; instead, elements are integrated progressively -- almost continuously. With RUP, what used to be a lengthy time of uncertainty and pain -- taking up to 40% of the total effort at the end of a project -- is broken down into six to nine smaller integrations involving fewer elements.
• Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier. As you unroll the early iterations, you test all process components, exercising many aspects of the project, such as tools, off-the-shelf software, people skills, and so on. You can quickly see whether perceived risks prove to be real and also uncover new, unsuspected risks when they are easier and less costly to address.
• Iterative development provides management with a means of making tactical changes to the product -- to compete with existing products, for example. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology.
• Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning. Design reviews in early iterations allow architects to spot potential opportunities for reuse, and then develop and mature common code for these opportunities in subsequent iterations.
• When you can correct errors over several iterations, the result is a more robust architecture. As the product moves beyond inception into elaboration, flaws are detected even in early iterations rather than during a massive testing phase at the end. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery.
• Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on. In a non-iterative development, the same people would be waiting around to begin their work, making plan after plan but not making any concrete progress. What can a tester test when the product consists of only three feet of design documentation on a shelf? In addition, training needs, or the need for additional people, are spotted early, during assessment reviews.
• The development process itself can be improved and refined along the way. The assessment at the end of an iteration not only looks at the status of the project from a product or schedule perspective, but also analyzes what should be changed in the organization and in the process to make it perform better in the next iteration. Project managers often resist the iterative approach, seeing it as a kind of endless and uncontrolled hacking. In the Rational Unified Process, the iterative approach is very controlled; the number, duration, and objectives of iterations are carefully planned, and the tasks and responsibilities of
participants are well defined. In addition, objective measures of progress are captured. Some reworking takes place from one iteration to the next, but this, too, is carefully controlled.

The RUP Is a Process Product

The RUP is not just a book, a development method developed and published once and for all in paper form. "Software processes are software, too," In contrast with the dusty binder approach, the Rational Unified Process is designed, developed, delivered, and maintained like any software tool. The Rational Unified Process shares many characteristics with software products:

• Like a software product, the Rational Unified Process is designed and documented using the Unified Modeling Language (UML). An underlying object model, the Unified Software Process Model (USPM) provides a very coherent backbone to the process.

• It is delivered online using Web technology, not in books or binders, so it's literally at the developers' fingertips.

• Regular software upgrades are released by Rational Software approximately twice a year. So the process is never obsolete, and its users benefit from the latest development. All team members access the same version of the process.

• Because it is modular and in electronic form, it can be tailored and configured to suit the specific needs of a development organization, something that's hard to do with a book or a binder.

• It is integrated with the many software development tools in the Rational Suites, so developers can access process guidance within the tool they are using.

The RUP Is a Software Engineering Process

Many organizations have slowly become aware of just how important a well-defined and well-documented software development process is to the success of their software projects. The development of the CMM (Capability Maturity Model) by the Software Engineering Institute (SEI) has become a beacon, a standard to which many organizations look, when
they aim at attaining level 2, 3, or higher. Over the years, these organizations have collected their knowledge and shared it with their developers. This collective know-how often grows out of design methods, published textbooks, training programs, and small how-to notes amassed internally over several projects. Unfortunately, in practice, these internally developed processes often end up gathering dust in nice binders on a developer's shelf -- rarely updated, rapidly becoming obsolete, and almost
never followed. Other software development organizations have no process at all, and need a starting point, an initial process to jump-start them on the path of faster development of better quality software products.

The RUP can help both kinds of organizations, by providing them with a mature, rigorous, and flexible software engineering process.

Rational Unified Process

What exactly is the Rational Unified Process, or RUP as many call it now? I can give several answers to this question, from different perspectives: 

• What is the purpose of the RUP?
It is a software engineering process, aimed at guiding software development organizations in their endeavors.

• How is the RUP designed and delivered?
It is a process product, designed like any software product, and integrated with the Rational suites of software development tools.

• What is the structure of the RUP; how is it organized internally?
The RUP has a very well-defined and regular structure, using an object-oriented approach for its description.

• How would an organization proceed to adopt the RUP?
The RUP is a process framework that allows a software development organization to tailor or extend the RUP to match its specific needs.

• What will I find in the RUP?
It captures many of modern software development's best practices harvested by Rational over the years, in a form suitable for a wide range of projects and organizations.

RUP Iterations and Workflows

>Business Modeling
>Requirements
>Analysis and Design
>Implementation and Test
>Deployment
>Configuration and change management
>Project Management
>Environment

RUP Overview and Phases

Overview
-A software framework that allows you to implement a methodology and process unique to your organization.
-A unification of the best software engineering practices of the last thirty years:
    -Promotes consistent business use case documentation
    -Promotes consistent analysis and design documents

    -Promotes consistent component based iterative development

Phases
    -Inception - Ensures that a project is both worth doing and possible to do.
    -Elaboration - Determines the architecture and the components for the project along with initial prototypes.
    -Construction - Complete the development based upon the initial architecture.
    -Transition - Insure that the software is available to the end users.

What does it mean to “be agile”?

The answer is more complicated than you might think. Agile development isn’t a specific process you can follow. No team practices the Agile method. There’s no such thing.

A method, or process, is a way of working. Whenever you do something, you’re following a process. Some processes are written, as when assembling a piece of furniture; others are ad hoc and informal, as when I clean my house.

Agile methods are processes that support the agile philosophy. Examples include Extreme Programming and Scrum.

Agile methods consist of individual elements called practices. Practices include using version control, setting coding standards, and giving weekly demos to your stakeholders. Most of these practices have been around for years. Agile methods combine them in unique ways, accentuating those parts that support the agile philosophy, discarding the rest, and mixing in a few new ideas. The result is a lean, powerful, self-reinforcing package.

Spiral Methodology

Waterfall methodology

System Development Life Cycle (SDLC)

Initiation Phase
The initiation of a system (or project) begins when a business need or opportunity is identified. A Project Manager should be appointed to manage the project. This business need is documented in a Concept Proposal. After the Concept Proposal is approved, the System Concept Development Phase begins.

System Concept Development Phase
Once a business need is approved, the approaches for accomplishing the concept are reviewed for feasibility and appropriateness. The Systems Boundary Document identifies the scope of the system and requires Senior Official approval and funding before beginning the Planning Phase.

Planning Phase
The concept is further developed to describe how the business will operate once the approved system is implemented, and to assess how the system will impact employee and customer privacy. To ensure the products and /or services provide the required capability on-time and within budget, project resources, activities, schedules, tools, and reviews are defined. Additionally, security certification and accreditation activities begin with the identification of system security requirements and the completion of a high level vulnerability assessment.

Requirements Analysis Phase
Functional user requirements are formally defined and delineate the requirements in terms of data, system performance, security, and maintainability requirements for the system. All requirements are defined to a level of detail sufficient for systems design to proceed. All requirements need to be measurable and testable and relate to the business need or opportunity identified in the Initiation Phase.

Design Phase
The physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval must be documented and reviewed by the user. The physical characteristics of the system are specified and a detailed design is prepared. Subsystems identified during design are used to create a detailed structure of the system. Each subsystem is partitioned into one or more design units or modules. Detailed logic specifications are prepared for each software module.

Development Phase
The detailed specifications produced during the design phase are translated into hardware, communications, and executable software. Software shall be unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested.

Integration and Test Phase
The various components of the system are integrated and systematically tested. The user tests the system to ensure that the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system. Prior to installing and operating the system in a production environment, the system must undergo certification and accreditation activities.

Implementation Phase
The system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements.

Operations and Maintenance Phase
The system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and needed system modifications are incorporated. The operational system is periodically assessed through In-Process Reviews to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organization’s needs. When modifications or changes are identified as necessary, the system may reenter the planning phase.

Disposition Phase
The disposition activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the system, so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.

System Development Life Cycle (SDLC)

Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.

To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.

The oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:

Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
Implementation: The real code is written here.
Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
But It Doesn't Work!

The waterfall model is well understood, but it's not as useful as it once was. In a 1991 Information Center Quarterly article, Larry Runge says that SDLC "works very well when we are automating the activities of clerks and accountants. It doesn't work nearly as well, if at all, when building systems for knowledge workers -- people at help desks, experts trying to solve problems, or executives trying to lead their company into the Fortune 100."

Another problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed.

The fountain model recognizes that although some activities can't start before others -- such as you need a design before you can start coding -- there's a considerable overlap of activities throughout the development cycle.

The spiral model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses. It's actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project. This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the disorderly, even chaotic evolution of technology.

Build and fix is the crudest of the methods. Write some code, then keep modifying it until the customer is happy. Without planning, this is very open-ended and can by risky.

In the rapid prototyping (sometimes called rapid application development) model, initial emphasis is on creating a prototype that looks and acts like the desired product in order to test its usefulness. The prototype is an essential part of the requirements determination phase, and may be created using tools different from those used for the final product. Once the prototype is approved, it is discarded and the "real" software is written.

The incremental model divides the product into builds, where sections of the project are created and tested separately. This approach will likely find errors in user requirements quickly, since user feedback is solicited for each stage and because code is tested sooner after it's written.

Big Time, Real Time

The synchronize and stabilize method combines the advantages of the spiral model with technology for overseeing and managing source code. This method allows many teams to work efficiently in parallel. This approach was defined by David Yoffie of Harvard University and Michael Cusumano of MIT. They studied how Microsoft Corp. developed Internet Explorer and Netscape Communications Corp. developed Communicator, finding common threads in the ways the two companies worked. For example, both companies did a nightly compilation (called a build) of the entire project, bringing together all the current components. They established release dates and expended considerable effort to stabilize the code before it was released. The companies did an alpha release for internal testing; one or more beta releases (usually feature-complete) for wider testing outside the company, and finally a release candidate leading to a gold master, which was released to manufacturing. At some point before each release, specifications would be frozen and the remaining time spent on fixing bugs.

Both Microsoft and Netscape managed millions of lines of code as specifications changed and evolved over time. Design reviews and strategy sessions were frequent, and everything was documented. Both companies built contingency time into their schedules, and when release deadlines got close, both chose to scale back product features rather than let milestone dates slip.

Pitfalls to avoid- JAD sessions

-Sponsor not really committed - no resources
-Unclear goals or objectives - lack of direction
-Too many or too few members
-Not enough communication with outsiders affected by decisions
-Timelines aren't kept
-Project Creep - project grows beyond the original definition and scope if this really needs to happen, it is time to rewrite the project charter
-Meetings aren't well facilitated
     -don't have an agenda
     -don't stick to agenda
     -don't begin or end on time
    -feels like nothing is accomplished in the meeting - old items not within scope keep getting revisited over and over
-1 or 2 members dominate discussions

How do you know if your JAD is successful?

Questions to ask
    -Are your meetings well attended?
    -Are all affected parties involved/aware of decisions being made?
    -Did you solve the true underlying problem?
    -Is your solution accepted and used by your clients? 
    -Is the solution available on time?

Success Factors
   -A clear purpose shared by all team members - the project charter
   -A diverse team, representative of all areas effected by this project.
   -Every person in the group has equal responsibility and decision making power.
   -Every idea is valuable. Throughout the JAD, listen and acknowledge each idea and concern. 

   -Evaluating ideas during a brainstorming session will shut down the creative process. The best idea may never get said out of fear of being shot down.
   -Participation by everyone is very important. Encourage quieter members to speak, they often have the best ideas. Don't allow 1 or 2 members to dominate. This is the facilitators responsibility as well as the whole teams' responsibility.
   -Listen when others speak, don't interrupt or talk while others are talking (side conversations may have great ideas...we don't want to miss them).
   -Maintain a parking lot to record important issues that are not within the scope of this project.
   -Don't hold meetings, just to hold meetings. Only meet when there is something substantial to talk about.
   -Don't let more than 3 or 4 weeks pass between meetings, you will loose momentum. 

   -Remember, each meeting is a motivation for the team to complete tasks assigned. It is no fun to come to a meeting and admit you didn't finish your task.
   -Decisions are reached by consensus. We are here to create a win/win solution...win/lose solutions aren't good enough. You can reach consensus by giving everyone three options:
           -Thumbs up - I agree
           -Thumbs down - I disagree
           -Thumbs sideways - I can support this idea

Checklist for getting a JAD session started

1. Define the Project

The JAD Project Leader meets with the Project Sponsor to complete a JAD Project Charter.

2. Form the JAD Group

The Project Leader and Project Sponsor form the JAD Group making sure you have all affected areas represented. You will need a Project Sponsor, Project Leader, Business Users and Systems Analysts. A JAD Group should have 8 or fewer total members. It is hard to be effective with more than 15 members.

3. First JAD Meeting - Kick off Meeting

Your first JAD meeting may have the following agenda items:

Share problem definition and overall goal. Get consensus on these two items.
Train each member of the new group on what a JAD Group is so they will understand the purpose, the roles and how a JAD works.
Establish JAD Group expectations/responsibilities.
Determine meeting frequency, time and place.
Determine roles - Project Sponsor, Project Leader, Record Keeper, Timekeeper, Clients.
Continue holding JAD meetings approximately every week or every other week until you have reached consensus on a design.

4. JAD Meetings - Planning, Analysis, Design Phase

Review the current process - map it out
Identify Problems/Challenges in the current process
Brainstorm solutions for those problems and challenges
Benchmark other organizations for possible solutions
Consider Buy vs. Build
Survey your customers for problems and ideas
Evaluate list of generated ideas
Determine your course of action - tasks to be accomplished
Develop your timebox - list of tasks, who is assigned and when each task is due.
Present the Project Design to the Project Sponsor and Representative Customers and Get the Thumbs Up
Communicate, Communicate, Communicate

5. JAD Meetings - Development, Execute, Finish Phase

Meet every 2 weeks to make sure the development stays on track Agenda - how did we do on our goals?

Discuss problems and challenges
Make decisions jointly
Set goals for next meeting
Assign tasks

6. Assign Duties

Assign as many of the project duties as possible to members of the JAD - this helps build buy in and a feeling of ownership towards the project.

JAD-Joint Application Development

Joint Application Development (JAD) is a popular fact-finding technique that brings users into the development process as active participants.

Process:

The JAD process is based on four simple ideas:
People who actually do a job have the best understanding of that job.
People who are trained in information technology have the best understanding of the possibilities of that technology.
Information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and affect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.
The best information systems are designed when all of these groups work together on a project as equal partners.

The JAD process does for computer systems development what Henry Ford did for the manufacture of automobiles (a method of organizing machinery, materials, and labor so that a car could be put together much faster and cheaper than ever before – the assembly line). The goal in systems development is to identify what the users really need and then set up a system or process that will provide it.

Typical session agenda:

Project leader or Business Analyst:
Introduce all JAD team members
Discuss ground rules, goals, and objectives for the JAD sessions
Explain methods of documentation and use of CASE tools, if any

Top management (sometimes called the project owner or sponsor): Explain the reason for the project and express top management authorization and support.

Project Leader or Business Analyst:
Provide overview of the current system and proposed project scope and constraints
Present outline of specific topics and issues to be investigated.

Open discussion session, moderated by project leader:
Review the main business processes, tasks, user roles, input, and output
Identify specific areas of agreement or disagreement
Break team into smaller groups to study specific issues and assign group leaders.

JAD team members working in smaller group sessions, supported by IT staff:
Discuss and document all system requirements
Develop models and prototypes.

Group leaders:
Report on results and assigned tasks and topics
Present issues that should be addressed by the overall JAD team
Open discussion session, moderated project leader:
Review reports from small group sessions
Reach consensus on main issues
Document all topics

Project leader or Business Analyst:
Present overall recap of JAD session
Prepare report that will be sent to JAD team members

False Requirements-Requirement Elicitation

In project management, requirements describe how a product or service should act, appear, or perform. These details explain the features and functions of the products or deliverables the project needs to have.

If you could ask your clients about requirements and know they were responding with exactly everything they needed, gathering requirements would be a piece of cake. However, in the course of the requirements-gathering process, it just usually isn’t that easy.

In fact, you’ll often hear information from clients that, on the surface, appear to be requirements when they actually aren’t requirements at all. We call these items false requirements.

False requirements come in many forms. Here are some of the more prevalent categories:

Vague requirements: How many times does a client offer a statement that contains a hint of one or more requirements but doesn’t offer any kind of specifics? Vague requirements require good follow-up and probing questions to make sure you have the correct level of detail. For instance, your sponsor might tell you, “I want this application to make employees’ lives easier.” This is not specific enough to be a requirement. You need to ask some follow-up questions to learn exactly how the client wants the application to help employees.

Opinions: While opinion statements can be requirements, many times they’re not. In many cases, the client will provide an opinion on the features and functions of a deliverable, and these are valid statements. However, if a client manager tells you that he thinks the company is spending too much money on the project, he’s offering an opinion — not a requirement.

Project-related statements: Requirements describe deliverables — not the project. For example, if a client tells you that “we should prototype this solution first,” he’s giving you input for the project approach — not a requirement. If a client states that she wants the project completed by a certain date, she’s giving you a schedule constraint — not a requirement.

Out-of-scope statements: When gathering requirements, you may find that you get off on a tangent (either related or unrelated to the discussion). For instance, when discussing a set of reports, the client might remark that a coworker has a new printer and that she would like a similar one. This is not a requirement; it’s out of scope for the purposes of the reporting discussion.

Comments from the wrong person: It’s important to know the role of a person providing requirements, so you can determine if the information he’s providing is consistent with his authority. For example, a user might tell you, “I think we should allow our vendors access to this information.” This isn’t a requirement since the typical user doesn’t have the power to make this type of decision.

Unrealistic or not testable: You might hear requirements that are really just marketing hype or extreme hyperbole. For instance, a client manager may tell you, “This product needs to be able to run on the moon.” This isn’t a real requirement since you can’t test or validate it. Make sure to ask follow-up questions to determine the real requirements behind the statement.

Learning how to quickly recognize these false requirements and how to dig deeper for the details is vital for a project manager. It can help save time in reworking the project as well as prevent further confusion later in the project.

Requirements Elicitation Guidelines

    -Assess System Feasibility
    -Be sensitive to organizational and political considerations
    -Identify and consult system stakeholders
    -Record requirements sources
    -Use Business concerns to drive requirements elicitation
    -Look for domain constraints
    -Record requirements rationale
    -Collect requirements from multiple viewpoints
    -Prototype poorly understood requirements
    -Use scenarios to elicit requirements
    -Define operational processes
    -Reuse requirements

Identify and Consult System Stakeholders
    -If lacking consideration of everyone who is likely to be affected by the introduction of the system, there is a great likelihood of missing some critical requirements.

    -“Identifying stakeholders and discussing the system with them makes people feel like they are part of the requirements elicitation process. In fact, it makes them a part of it.”

Use Business Concerns to Drive Requirements Elicitation
    -If a system is to be useful, it must contribute to the key concerns of the business. If the concerns are identified and used as drivers of the requirements elicitation process, there will be higher confidence that the system will meet real organization needs.

    -Making the business concerns explicit helps to focus and clarify these goals.

Collect Requirements from Multiple Viewpoints
    -If requirements are collected from a single viewpoint, they are unlikely to meet other stakeholders’ requirements.
    -Collecting requirements from multiple viewpoints is a useful way to prioritize requirements
    -Identified viewpoints can be used to help
        -organize requirements elicitation and
        -organize the requirements specification, too.

Reuse Requirements
    -Saves money and time. Studies have shown that similar systems can re-use up to 80% of the requirements.
    -Reuse reduces risk. Reused requirements have a better chance of being understood by all the stakeholders.
    -Requirements reuse may lead to additional reuse in other lifecycle activities.
        -Component design
        -Tests
        -Code

Preparing for the Workshop

Role of the Facilitator
    -Establish professional and objective tone to the meeting.
    -Start and stop the meeting on time.
    -Establish and enforce the “rules” for the meeting.
    -Introduce the goals and agenda for the meeting.
    -Manage the meeting and keep the team “on track.”
    -Facilitate a process of decision and consensus making, but avoid participating in the content.
    -Make certain that all stakeholders participate and have their input heard.
    -Control disruptive or unproductive behavior.
Workshop Agenda
    -Set an agenda before the workshop and publish it along with the other pre-workshop documentation.
    -Balance is the key, try to stay on the agenda, but do not strictly obey it, especially if good discussion is going on.
    -Order lunch in, and have a light working lunch. :-)
Running the Workshop
    -Allow for human behavior, and have fun with it.
    -Do not “attack” other members.
    -Do not get on a soap box.
    -Do not come back late from a break.
    -Workshop tickets
        -Give every stakeholder 3 workshop tickets
                -1 for being late
                -1 for “cheap shot”
                -1 for “soap box”
    -Facilitator takes tickets when appropriate. If you do not have a ticket create a fund to add to, like $1 to pot for after workshop activities.
Workshop Problems and Suggestions
    -Time Management
            It’s difficult to get going after breaks and lunch.
            Key shareholders may be late returning
            Grandstanding, domineering positions
            Lack of input from stakeholders
    -Negative comments, petty behaviors, and turf wars
    -Flagging energy after lunch
    -Facilitator keeps a timer for all breaks and fines anyone that is late, everyone gets one free pass.
    -Everyone gets one 5 minute position statement.
    -Facilitator encourages everyone to use 5-minute position and great idea ticket.
    -Use “Cheap Shot Tickets”, all others cost money.
    -Lite lunches, afternoon breaks, rearrange seating

Requirements Elicitation Techniques

Requirements Elicitation Techniques
Interviewing and questionnaires
   -Simple direct technique
   -Context-free questions can help achieve bias-free interviews
   -Then, it may be appropriate to search for undiscovered requirements by exploring solutions.
   -Convergence on some common needs will initiate a “requirements repository” for use during the project.
   -A questionnaire is no substitute for an interview.

Interview: Context free question
Goal is to prevent prejudicing the user’s response to the questions.
Examples:
Who is the user?
Who is the customer?
Are their needs different?
Where else can a solution to this problem be found?
Context-free questions also parallel the questions salespeople are taught to ask as part of a technique called “solutions selling.”
After context-free questions are asked, suggested solutions can be explored.

Interview: Show time
Establish Customer or User Profile
Assessing the Problem
Understanding the User Environment
Recap the Understanding
Analyst’s Inputs on Customer’s Problems
Assessing Your Solution (if applicable)


Requirements workshops
Technique: Requirements Workshop
   -The requirements workshop is perhaps the most powerful technique for eliciting requirements.
   -It gathers all key stakeholders together for a short but intensely focused period.
   -The use of an outside facilitator experienced in requirements management can ensure the success of the workshop.
   -Brainstorming is the most important part of the workshop.

Preparing for the workshop
   -Selling the workshop concept to stakeholders
   -Ensuring the Participation of the Right Stakeholders
   -Logistics
   -Try and prevent Murphy’s law
   -Includes travel, lighting, and even “afternoon sugar filled snacks.”
   -Warm-up materials
   -Project-specific information
   -Out-of-box thinking preparation

Braining Storming and idea reduction
   -Brainstorming involves both idea generation and idea reduction.
   -The most creative, innovative ideas often result from combining, seemingly unrelated ideas.
   -Various voting techniques may be used to prioritize the ideas created.
   -Although live brainstorming is preferred, web-based brainstorming may be a viable alternative in some situations

Storyboards
   -The purpose of storyboarding is to elicit early “Yes, But” reactions.
   -Storyboards can be positive, active, or inactive.
   -Storyboards identify the players, explain what happens to them, and describes how it happens.
   -Make the storyboard sketchy, easy to modify, and unshippable.
   -Storyboard early and often on every project with new or innovative content.

Use Cases
   -Use Cases, like storyboards, identify the who, what, and how of system behavior.
   -Use Cases describe the interactions between a user and a system, focusing on what they system “does” for the user.
   -The Use Case model describes the totality of the systems functional behavior.
   -Early stages: After you have an overview of the use cases, perhaps only by a phrase apiece, expand 10% of them in detail.
   -More later …


Role Playing
Technique: Role Playing – variant on use cases
   -Role playing allows stakeholders to experience the user’s world from the user’s perspective.
   -A scripted walkthrough may replace role playing in some situations, with the script becoming a live storyboard.
(Class-Responsibility-Collaboration (CRC) cards, often used in object-oriented analysis, are a derivative of role playing.)

Prototyping
   -Prototyping is especially effective in addressing the “Yes, But” and the “Undiscovered Ruins” syndromes.
   -A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understand system requirements.
   -Prototype the “fuzzy” requirements: those that, although known or implied, are poorly defined and poorly understood.

Problems of Scope-Requirement Elicitation II

If requirements elicitation begins without an appreciation for organizational context, then a number of restricting assumptions are made due to “misconceptions, management politics, technical ignorance, mistrust, established practices, personnel resistance, ...”
Environmental factors have a strong influence on requirements elicitation “The process for eliciting the work-group and end-user requirements are premised on the notion that sound and accurate descriptions of the users and their environment is at first
necessary.” Environmental factors include:
• hardware and software constraints imposed on a target system (the target
system will typically be a component of some larger system with an existing
or required architecture already in place)
• the maturity of the target system’s domain
• the certainty of the target system’s interfaces to the larger system
• the target system’s role within a larger system

Environmental constraints are introduced because the system under development is rarely a stand-alone system but instead must interface with a larger system. This premise allows the requirements engineer to restrict the requirements analysis to the universe of discourse established by this larger system.
Environmental constraints can have a profound impact on the requirements elicitation process. The specialization of this process to a particular architecture or domain allows requirements elicitation to focus on problems that either have lower priority or do not exist in other application domains“performing requirements analysis for an application area may require specific methods and tools that are not necessary for other types of application.”


The project context also affects the requirements and requirements engineering process.
Project factors include:
• the attributes of the different stakeholder communities, such as the end
users, sponsors, developers, and requirements analysts. Examples of such
attributes are:
• management style
• management hierarchy
• domain experience
• computer experience
• the constraints imposed by the people involved in the elicitation process, e.g., managerial constraints concerning cost, time, and desired quality in the target system.

Problems of Scope-Requirement Elicitation

Elicitation techniques need to be broad enough to establish boundary conditions for the target system, yet still should focus on the creation of requirements as opposed to design activities. Avoiding contextual issues can lead to requirements which are incomplete, not verifiable, unnecessary, and unusable. Focusing on broader design activities improperly emphasizes developers’
issues over the users’ needs and may result in poor requirements as well. Requirements elicitation must begin with an organizational and context analysis to determine the boundary of the target system as well as the objectives of the system. Less ambitious elicitation techniques not addressing this concern run the risk of producing requirements which
are incomplete and potentially unusable, because they do not adhere to the user’s or organization’s true goals for the system. Performing an organizational and context analysis allows these goals to be captured, and then used to verify that the requirements are indeed usable and correct.
Elicitation techniques can be overly ambitious as well. Elicitation must focus on the creation of requirements, not design activities, in order to adequately address users’ concerns and not just developers’ needs. Elicitation strategies which produce requirements in the form of high level designs run the risk of creating requirements which are ambiguous to the user community.
These requirements may not be verifiable by the users because they cannot adequately understand the design language. Also, requirements expressed as a design are much more likely to incorporate additional decisions not reflecting user or sponsor needs, i.e., the requirements will not be precise and necessary.
There are at least three broad contexts which affect the requirements and the requirements engineering process for a proposed system:
• organization
• environment
• project
Requirements elicitation necessitates an understanding of the organization in which the system under development will be placed, as well as an understanding of the system’s mission within the organizational context: “the primary interest of customers is not in a computer system, but rather in some overall positive effects resulting from the introduction of a computer system in their environment” . This view is not well reflected in current practice, where requirements elicitation concentrates on the computer system without much concern for organizational factors. Organizational factors include:
• submitters of input to the target system
• users of the target system’s output
• ways in which the target system will change the organization’s means of doing business

Requirements Elicitation Problems

Problems of requirements elicitation can be grouped into three categories:
• problems of scope, in which the requirements may address too little or too
much information;
• problems of understanding, within groups as well as between groups such as
users and developers; and
• problems of volatility, i.e., the changing nature of requirements.
The list of ten elicitation problems given in one source [McDermid 89] could be classified according
to this framework as follows:
• problems of scope
   • the boundary of the system is ill-defined
   • unnecessary design information may be given
• problems of understanding
   • users have incomplete understanding of their needs
   • users have poor understanding of computer capabilities and limitations
   • analysts have poor knowledge of problem domain
   • user and analyst speak different languages
   • ease of omitting “obvious” information
   • conflicting views of different users
   • requirements are often vague and untestable, e.g., “user friendly” and “robust”
• problems of volatility
   • requirements evolve over time

The Process of Requirements Elicitation

Requirements Engineering process is categorized into three activities. 

1. elicit requirements from various individual sources;
2. insure that the needs of all users are consistent and feasible; and
3. validate that the requirements so derived are an accurate reflection of user needs.
     

This model implies a sequential ordering to the activities, with elicitation done once at the very beginning of the process. In reality, though, the process is iterative, with these activities revisited many times.

Thus, while requirements elicitation consists of the earliest activities in the requirements engineering process, it can not be divorced from the subsequent activities. Elicitation will likely iterate with these other activities during requirements development.

Requirements elicitation itself can be broken down into the activities of fact-finding, information gathering, and integration.

Requirement elicitation process is further decomposed as follows.
        1. Identify the relevant parties which are sources of requirements. The party might be an end user, an interfacing system, or environmental factors.
       2. Gather the “wish list” for each relevant party. This wish list is likely to originally contain ambiguities, inconsistencies, infeasible requirements, and untestable requirements, as well as probably being incomplete.

      3. Document and refine the “wish list” for each relevant party. The wish list includes all important activities and data, and during this stage it is repeatedly analyzed until it is self-consistent. The list is typically high level, specific to the relevant problem domain, and stated in user-specific terms.
     4. Integrate the wish lists across the various relevant parties, henceforth called viewpoints, thereby resolving the conflicts between the viewpoints. Consistency checking is an important part of this process. The wish lists, or goals, are also checked for feasibility.

     5. Determine the nonfunctional requirements, such as performance and reliability issues, and state these in the requirements document.

Requirements Definitions

Requirements do not only consist of functions, a misconception introduced in part because the
currently popular structured analysis techniques focus on articulating functional requirements.
Different authors will present different definitions, but there are clearly nonfunctional requirements
as well as functional requirements. In one source, requirements are classified as follows

1. functional requirements
2. nonfunctional requirements
      a. performance/reliability
      b. interfaces
      c. design constraints

Requirement Characteristics

Characterisitcs of a Requirement
Requirements are more than just statements that describe the needs of a client. Good requirements are written in a certain way and have certain characteristics that make them more valuable in how they describe the solution. Some of the characteristics may be built into the requirements when they are initially captured.

Necessary - essential to the purpose of the product
Good requirements should be must have and should be very much in the scope of the project.

Accurate - correct in its description of features & functions
Each requirement must be correct and precise in how it describes the features or function of the solution.

Clear - not subject to interpretation or presumption
Must be straightforward, must be obvious to its meaning and should not have any misinterpretations.

Complete - without need for further clarification
Each requirement represents a full result and not a partial result. Many requirements may contribute to the overall feature of function, but multiple requirements should not be needed to complete one discrete need of the client.

Consistent - with all other requirements
Requirements should not be in conflict with other requirements, they should not contradict the other requirements.

Testable - capable of verification and validation
You need to be able to validate if the requirement exists and is correct, no requirement should be documented that are not testable.

Traceable - through its evolution of development
Requirement should be traceable through out the entire system development life cycle. If a requirement is not traceable in the test phase then it is considered not to be a real requirement.

Requirements should be documented and traced through out the SDLC.

But in the end, make sure: The design of the solution, Matches the nature of the problem

Business Requirements

The term Business Requirement has two general meanings. First the term is used to describe all of the requirements. For a general sense all requirements are driven by a business need, and therefore all of the requirements are business requirements.

The second way the business requirements is used to differentiate requirements that are driven by business needs versus those requirements that are driven by technological needs. These are not business requirements as the business client does not care of the technical requirements. In the systems development life cycle these are not really requirements but part of the technical architecture and design phase.

Types of Requirements

To further define requirements, it is important to make some fundamental distinctions and categorizations.

1. Business Requirements

2. Technical Requirements

3. Product or Service based Requirements

4. Process Requirements

5. Role-based Requirements
              a. Client Requirements
              b. User Requirements
              c. Sponsor Requirements
              d. IT Requirements
              e. Security Requirements
              f. Auditing Requirements

              etc.....

What is a Requirement?

Before you begin to gather requirements in the analysis phase and decide what techniques are used to capture them, you must first understand what a requirement is and what the different types of requirements are. Requirements are descriptions of how a product or service should act, appear or perform. Generally the term applies to a new ( or enhanced ) product or service.

A Requirement typically refers to some aspect of a new or enhanced product or service.

Business Analysis

Business analysis involves soliciting, analyzing and documenting a set of business requirements that a solution to a business problem must satisfy. For information systems, requirements generally fall into the following Architectural Categories:

Business Concepts and Data
Business Processes and Functions
Business Locations and Communications
Business Roles and Interactions
Business Events and Schedules
Business Policies, Procedures and Rules

In addition to requirements, analysts will solicit information and act as facilitator among various organizational groups in order to discover potential risks and gaps within the proposed solution. This may extend into a full cost-benefit analysis of potential projects in order to advise management on the project's expected value to the business.

Once Requirements are stable (enough), and a project is in progress, they will act as a facilitator between the business team and the development team. Because of the wide variety of projects that may be encountered, the analyst must be familiar with, and have a working knowledge of various modeling and development theories and methodologies.

The Business Analysts normally liaise with the stakeholders of business enterprises to identify current and future business requirements as well as with Enterprise Architects to enable their development of business blueprints. They also conduct business gap analysis to plan appropriate technology implementation in alignment with business goals.

Who is a Business Analyst?

The term Business Analyst (BA) is used to describe a person who practices the discipline of business analysis. A business analyst or "BA" is responsible for analyzing the business needs of their clients to help identify business problems and propose solutions. Within the systems development life cycle domain, the business analyst typically performs a liaison function between the business side of an enterprise and the providers of services to the enterprise. Common alternative titles are business systems analyst, systems analyst, and functional analyst, although some organizations may differentiate between these titles and corresponding responsibilities.

Business Analyst Definition
The business analyst is skilled at working with end-users to determine what their needs are. Often, the business analyst has some technical experience which is useful in determining if a user's requests are feasible. Note that the business analyst is more than just a glorified note taker as he is also responsible for drilling down in to each business requirement to ensure that what is being asked is actually what is needed. Often a user thinks a particular feature is needed when in fact it isn't. Similarly, a user may assume that a particular feature will be included when it hasn't been specified anywhere.

It is also the business analysts role to translate what the user is asking for into a technical form that the client/server programmer or web developer can understand.