What is Computer Programming Business Requirements Analysis? A focused and detailed Business Requirements Analysis can help you avoid costly issues. This is the process of discovering, analyzing, defining, and documenting the requirements that are related to a specific business objective. Information Technology departments around the world have gone through many iterations in the last 80 years to become an integral part of modern day enterprises. Information Technology (IT) professionals may not be as highly regarded in their organizations as they should be.

I mean it’s 2019, and we still have organizations using Windows 7 with slow server connections, and a ton of missing features to the end user.

One of the reasons for this may be the relatively poor job that has been done understanding the clients needs and analyzing the business requirements.

Many moons ago, IT managers continuously asked the question:

“Why aren’t we coding yet?”

which clearly illustrated where the emphasis was. Programmers were seen as productive only if they were turning out pages of code. Little time was spent on design and even less on analysis. Even today, many of the current texts combine analysis and design as if they were one effort. I believe that this is the heart of the problem.

Budgets and resources are tight, time constraints are ever present, and the business is demanding changes, enhancements and new features and services like never before. It should probably be no surprise, then, that some shops are still not devoting time to doing analysis, under the misguided perception that shortcutting this activity will speed up the development process and save costs.

Haste makes waste.

Take a look at the requirements analysis historical comparison in the graph below.

System Development Life Cycle (SDLC) Historical Comparison – Computer Programming Business Requirements Analysis

As you can see the above graph depicts the end results are quite the opposite. The numbers on the Y-axis (vertical) represent a comparative measure rather than an absolute percentage. The X-axis horizontal axis represents the percentage of effort spent on a particular phase of the System Development Life Cycle (SDLC) (Analysis, Design, Coding, Testing, Production.)

In the Pre 1985 line (see image above) we can see only 5% of total system effort (where effort relates  to time spent and number of people involved) was spent on doing analysis whereas 30% was spent on design and 40% on coding.

Now, notice how the percentage changes as we Post 1985 line (see image above) and change yet again as we look at the respective efforts today 2019. The important end result of this change is that the total system costs less and takes less time. In other words, the more time that we invest in doing a thorough analysis, the more time, and therefore money, that we save in the whole system.

If you haven’t already noticed that post 1985 (see image above) spending too much time on analysis  (40%) may increase production times  (15%) compared to today’s (2019) production time of  (10%) when analysis time spent was (20%).

This research does not take into account the time and cost savings relating to post-production ‘fixes’ and changes. Another factor not reflected in graph above is the relative level of user satisfaction – a better; more timely and cost-efficient system makes for happier clients. Remember this is an overly simplified model there are several variables that affect this model such as currency values, laws, regulations and new standards, etc…

The failure in the 1980’s and 1990’s to define the business and system requirements up-front with a systematic approach to problem solving, resulted in significant costs in subsequent SDLC phases. The reason for this, we now know, is that the analysis activity was simply shifted into the other phases of the SDLC, resulting in additional effort and rework. Business requirements discovered during design, coding, or testing that should have been addressed and discovered during analysis result in significantly increased effort and therefore, cost. A further cost is born dealing with changes to requirements during maintenance and enhancement activities, where companies currently spend an average of 80% of department’s budget.

Devoting so much time to analysis that it interferes with the product delivery is not the answer either (see the Post 1985 line) In this highly competitive world, the IT department must respond better and faster, otherwise our users will look to other providers, or suffer from lack of productivity.

In today’s world, a method is needed that captures the users requirements quickly, accurately, and completely – one that provides a flexible, yet structured approach to producing a high quality specification on a consistent basis.

There are many theories on Systems Analysis as well as proprietary methodologies developed by consulting firms and major corporations around the world. Different methodologies may utilize different terms or use the same terms with slightly different versions.

So what really works?

We will touch on the generally accepted Best Practices organized in a such a way that will make it easy for you to learn and use in real world situations. ALL consultants in the industry use these Best Practices in hundreds of major corporations with great success. The methods are time-proven to work.

The Importance of Specifying Client Requirements

A fundamental and often underrated analysis activity is Specifying Client Requirements. In project management we say that one of the success factors of a project is that it satisfies the users needs or requirements. It would follow logically, then, that we would not hope to satisfy the users needs if we are unable to discover those needs.

The house can only be as strong as the foundation, and the foundation for any system is a comprehensive understanding of the business and  user/client requirements.

In the USA, more than $325 billion is spent each year on the application development of approximately 250,000 IT projects. The following are the average costs for a project in comparison to the company size:

The figures above also show that almost 38% of these application development projects will be cancelled before completion and almost 60% will cost 190% of their original estimates. Projects completed by some of the largest US companies (Facebook, Google, Microsoft, IBM, Walmart, Berkshire Hathaway, Apple, ExxonMobil, McKesson, UnitedHealth Group, CVS Health, General Motors, AT&T, Ford, Bell, & Tesla to name a few) have approximately 42% of the originally proposed features and functions, and that every 100 projects that start, there are 95 restarts, in some instances multiple restarts.

While these numbers are mind-boggling, what is even more mind-boggling are the simple reasons for these failures. The three top reasons were:

1. Lack of user involvement
2. Lack of executive management support, and
3. Unclear statements of requirements

Simplicity is the most difficult thing to secure in this world; it is the last limit of experience and the last effort of genius. George Sand.

Poor planning and unrealistic expectations were  other important factors. The importance of good user requirements on the success of IT applications development projects is obvious from the above data.

We cannot underestimate the importance of properly specifying client requirements in the overall success of application development projects. We focus on two aspects:

• Discovering, describing, and documenting the customer needs and expectations to obtain a better understanding of what will satisfy the customer requirements.
• Providing the basis for agreements between the customer and the systems engineering effort.

When we mention systems engineering, we are really talking about the remaining effort involved in completing the process, namely the design, coding, testing, and the implementation efforts or the remaining steps in the SDLC.

Systems Development Life Cycle (SDLC) – Computer Programming Business Requirements Analysis

In the above figure we see the phases of the Systems Development Life Cycle graphically represented as: Analysis, Design, Building (or coding), and Implementation. Other texts may break the SDLC down into 5, 6, 8, or even more phases but this model essentially represents the main phases are included in a typical application, from conception through to production.

Typically, we have done these phases sequentially or, perhaps, to our detriment, combined them. We think you will agree, however, that we must complete the Analysis before we begin the Design. A system design team cannot reasonably be expected to deliver a design to meet user’s needs if the needs are not defined. The same logic holds true, as we get deeper into the SDLC. We cannot start Building, or writing the program code, until we design the logic of how the system will function. The cost of making changes to the system increase dramatically the further into the SDLC the need for a change is discovered. Consideration must also be given to the cost of not making any changes – a system lacks required functionality, and disappointed users.

As we get deeper in to the SDLC, any changes will increase the cost exponentially because much effort already expended will have to be rethought and reworked. The later we make the change, the more the effect and the higher the cost. It makes sense, therefore, to ensure that our analysis is as complete as possible. There is, however, a point of diminishing returns where so much time is spent making sure that the analysis is complete, that there is little time or money left to complete the project. This is a practice that is referred to as analysis paralysis.

Who is involved?

So who is the customer we keep referring too? This is actually simpler than you think. The customer is the target audience of the business application or game that is being developed.

Specifying client requirements cannot be accomplished in a vacuum. The process must involve the active participation of some key players. These key players involve people from IT and from the user community. As we proceed through the SDLC, participation is more active from some players than from others depending on what phase of the SDLC we are in. Since we are concerned with specifying client’s requirements, or systems analysis, the users will be the most heavily involved since, without them, we could only guess at their business or gaming needs.

Included from the user area are the business area Subject Matter Experts, or SMEs, and the project sponsor. The subject matter experts, as the term implies, will include the individuals with the expertise in the user area, on whom we will rely to explain the intricacies of the area we are examining.

The project sponsor, as a representative of senior management is key to providing insight to the objectives of the project. The project sponsor is the one who usually supplies the funding for the project and is ultimately responsible for its success.

The Project Manager or Project Leader is an integral part of the project team. The project manager may be a member of the client/user community or the IT organization and possesses strong general, people and project management skills. The technical side of the project team may include Database Analysts, Systems Architects, Systems Analysts, and Programmer Analyst. During the business analysis phase, the technical subject matter experts and service providers are usually involved in order to observe, listen and understand rather than contribute to the requirements. The problem that often arises when technical experts are actively involved in the analysis phase is the risk of biasing the requirements, getting bogged down in detail, and moving into design and architecture issues too early. This is not a written in stone rule – it certainly depends very much on the actual people involved. It is often necessary to involve technical subject matter experts early in the development cycle to determine high-level design and technical constraints or opportunities. Valuable learning can be obtained by the technical design team when they are involved in the business requirements efforts as observers. This opportunity allows the technical experts to better understand the users concerns and needs.

The person or people responsible for the business requirements are known by many names:

• Business Analysts
• Requirements Analysts
• Requirements Architect
• and other variations.

This role may be filled by Systems Analysts, Programmer Analyst, or Project Leaders, depending on the size and complexity of the organization. In smaller organizations, there may not be a separate position, and analysis may be the responsibility of either the IT department or the business unit. Throughout this article we will often refer to the Business Requirements Analyst or Architect with the intent to mean the person who carries the analysis responsibilities as much as who has the position or title. As a Business Requirements Analyst, you often need to serve many masters – acting as service provider to the business client to assist them in defining and documenting their requirements and as ‘service providers’ to the IT designers and developers to be their intermediary with the business organizations and provide them with a specification they can use to develop a software solution.

The requirements discovery process must include people who fill other critical roles. These include someone to facilitate the requirements gathering (also called requirements elicitation) and someone or some people who will be responsible for the documentation, production and management of the deliverables and models, and someone to manage the status of the requirements. In many small and medium-size organizations, this is usually done by the individuals filling the position of the Business Requirements Analyst. Other organizations may employ professional Requirements Facilitators, Modelers, Technical Writers, and Requirements Managers to do the requirements discovery, documentation and management. Another very popular alternative that many companies (small and large) use is to outsource these services on a project to project basis to professional consulting services like MiltonMarketing.com who specializes in these services and use proven software engineering Best Practices and a defined and standardized approach to ensure a cost effective and successful project. Many of these Best Practices and many aspects of that approach are covered in this article.

We will continue to use the words: (3 Ds)

• Discover
• Describe
• Document

The 3 Ds represent the three main goals of a business requirements analyst or architect. You will see most of the analysis activities in this article have something to do with either the discovering, describing or documenting of the user’s business needs.

Background of Best Practices

The methodology that is detailed in this article was developed as the result of a number of factors, including ongoing research into the methods and practices that are being used in the IT profession and experience gained by applying the methods in the field in thousands of different situations. The selection of the appropriate “tool” must be considered in light of the four headings in image below:

SDLC Best Practices – Computer Programming Business Requirements Analysis

Best Practices – The Practices

There are many so-called experts and associated practices in our business. It is an on-going research activity at MiltonMarketing.com and No-Name Software Consultants to stay informed on what these practices offer and to select from them the ones that can be applied easily and effectively to gather client requirements in a manner consistent with what the standards specify. No one method will fit all organizations.

The pace of change in technology and business is resulting in the need for different ways of doing traditional system development tasks. New methods are being developed to meet these new conditions. Organizations are searching for guidance on the specifics of how to intitute key practices in the phases of developing or maintaining information systems. The approach that will be developed in this article incorporates elements from the following ‘gurus’:

• Event Process modeling from Yourdon, Demarco, McMenamin and Palmer
• Data Modeling from Bachman, Chen and Codd
• Information Engineering from Martin
• Object Oriented Analysis from Rumbaugh, Booch, and others.
• Use-case Scenarios from Jacobson
• Business Rules from Ross
• Advanced JAD
• General Systems Theory from Wienberg
• Tom Peters

Best Practices – The Principles: The Best Process

If you can’t find the time to do it right the first time, how are you ever going to find the time to do it over again, and again, and again?

In other words, in today’s competitive market, and belt tightening departmental budgets it’s not feasible to have an over budget project that keeps turning out unsuccessful. In order to obtain the best results, the resulting Business Requirements Specifications must be the true user requirements. If executed correctly the first time it will result in reduced work and cost later.

This will save time for the IT department which will mean reduced cost and will also save the users time which will result in much less frustration, and improved relations between IT and the user community. It must be accurate.

The requirements specification must be viewed as a comprehensive deliverable. While it is not realistic to expect to produce a specification that is 100% complete, we must try to approach that level of completeness in a reasonable amount of time. The specification must be flexible enough to handle the reduced, but inevitable changes that will occur. It must be complete.

There are two groups of players who are concerned with the results: the analysts and the users. The analysts who perform the requirements analysis and produce the resulting Business Requirements Specification may or may not be the same analysts who take it to the next step – the design phase. The people who take up the next phase must be able to understand the specifications without constantly referring back to the people who performed the analysis. The other interested party – the users, must also be able to understand the specifications because they are the people who must sign off responsibility on them or take ownership of the specifications, and the resulting system. It must be crystal clear.

One of the ways that we ensure our specifications are accurate, complete, and crystal clear, is by using a systematic approach to Discovering, Describing, and Documenting the users requirements. We call this the 3 Ds and will refer to them as such in this article.

As we are working with the user’s to discover their needs, we will use a tool called the discovery session, which we have already mentioned. In these discovery sessions, we want to make sure that we communicated effectively with the users. Other settings for requirements gathering might include small group interview, teleconferencing, questionnaires, and field observation. We will discuss the pros and cons of the various methods later on.

Best Practices – Objectives

Another factor that we consider in our selection of Best Practices is what organizations need from this phase of the SDLC – What are the Objectives? The deliverable from this process of Specifying Client Requirements is a Business Requirements Specification – a document that can be used by a number of different groups as the basis for their effort. This document will be used as input to the next phase of our efforts that may vary from buying a software package from a vendor to building our system from scratch, and any combination in between.

Now that the Electronic IT (Information Technology) age has been around since the 1940’s until today (approx 79 years), a number of packaged solutions have been developed that will satisfy many of our needs. The 80/20 rule applies to many situations and this is one of them. In sales, 80% of our revenue will come from 20% of our clients. In inventory control, 80% of our business will come from 20% of the products that we carry. In so far as IT is concerned, an off the shelf package will probably satisfy 80% of our requirements. The question here is How important are the remaining 20% of our needs that the package does not cover? This leads to the Build or Buy scenario. In some instances, we may find that a packaged solution is the most cost effective but how do we know, unless we do a thorough analysis of our users needs?

Organizations will expend months and in some cases years of effort to do analysis on a system that they plan to build but may not expend that type of effort when they plan to buy a system to do the same thing. The result may be that the users are unhappy because the purchased system does not meet their needs.

Once the analysis is complete, then that analysis can be used as the basis for building the system or as the basis for a Request for Proposal (RFP) to be submitted to various vendors. A little while back one of our clients, a manufacturing firm, needed a new system for their Help Desks across Canada. Management, on our recommendation, decided to buy the system as opposed to developing it from scratch. Our research had indicated over 30+ software companies that sold prepackaged Help Desk software and we saw no point in reinventing the wheel. If, after receiving all of the RFPs from the vendors, it was determined that none of the solutions sufficiently met our needs, we could still build our own or custom code an existing solution to reduce cost and time.

After doing a thorough analysis of the users requirements, we produced, in 5 days a Business Requirements Specification that was detailed enough to build the system from scratch. We then sent that document to the vendors and asked them to submit proposals based on it. We also told them that the requirements specification would be used as a basis for evaluating their proposals and would also serve as the basis for a binding legal agreement between the chosen vendor and us. With that level of details, there was no way that a vendor could sell us a product that did not meet our needs.

We narrowed the vendors down to a short list of three and invited them in so that we could test their software against our requirements. The personnel that worked on the Help Desks developed scripts that they could run on the proposed software packages and charted each features on the basis of how well they met our needs. Two weeks later, when the process was finished the users themselves had decided on the vendor with the package that best satisfied their requirements and the requirements specification was actually attached to the contract as an addendum.

MiltonMarketing.com was contracted to develop code to bring their package closer to the client’s needs and the users were very satisfied with the end results. Talk to any senior managers of companies that have purchased prepackaged software and we are willing to bet that their experience was far less satisfactory than our client’s for the simple reason that they knew exactly what they wanted before they bought.

Steve McConnell made the following comment concerning the critical activity that must occur in requirements gathering:

“The most difficult part of requirements gathering is not the act of recording what the users want; it is the exploratory developmental activity of helping users figure out what they want.” Steve McConnell.

It is not sufficient to simply record what the users say they need; it is vital that we have the tools to help the users figure out what it is that they need.

Best Practices – The ISO Standards

Although there are many standards groups available to the IT Industry, the two most commonly accepted standards groups that we have relied on are the Software Engineering Institute’s Capability Maturity Model (SEI-CMM) and the IEEE (Institute of Electrical & Electronics Engineers) Standards for Software Engineering.

The SEl-CMM outlines the characteristics of a mature, capable software process. The organization is especially known for its Capability Maturity Model that defines 5 levels of maturity in the Software Engineering business and then identifies Best Practices (organized by high-level process areas) required to achieve the levels identified. High-level process areas include: Planning, Engineering and Managing. We have gathered the most insight from the Engineering Process Area that is addressed through lower level process areas PA 01 PA 07 and most specifically on PA 06: Understand Customer Needs and Expectations (more about this later) and the Glossary of terms.

The IEEE standards are developed by Technical Committees of the IEEE Societies (e.g., the Computer Society) and represent the formalization of current norms of professional practice. The standards which contributed most in the development of this methodology are defined in:

• STD 1233-1996 “Guide for Developing of System Requirement Specifications”
• STD 610.12-1990 – “Glossary of Software Engineering Terminology”
• STD 830-1998 – “Recommended Practices for Software Requirements Specifications”.

The Software Engineering Institute stresses, in PA 06: Understand Customer Needs and Expectations, the importance of properly gathering user’s requirements by issuing the following Best Practices:

• Elicit the customer needs
• Analyze the customer needs
• Develop a statement of requirements
• Obtain customer agreement
• Inform customer on disposition of requirements

These steps form an integral part of Best Practices and, in this article, we will show you how to apply them simply and thoroughly. As further validation of the importance of properly gathering user’s requirements, IEEE Standard 1233 says that the process for gathering users requirements should:

• Be goal directed
• Define the system boundaries
• Ensure that all requirements are solicited, evaluated, and documented
• Specify requirements as capabilities affected by conditions and constraints
• Validate all requirements
• Consistently document the requirements
• Produce requirements that are understood by all

In addition, IEEE defines requirements as:

“Statements, which identify the essential needs for a system in order for it to have value and utility.”

“What functions are to be performed on what data.”

The Discovery Process

“When common sense is not so common.”

Our response to these standards is a process for discovering, describing and documenting – we call it The Discovery Process – that starts with a system concept and ends with a Statement of User Requirements. This process uses various Best Practices at appropriate points in the process to effectively achieve our goals.

We have divided the discovery process into 4 basic sections:

• Describing Objectives and Scope
• Discovering and Describing the Functionality
• Discovering and Describing the Information
• Refining and Documenting the Requirements

We will dive into each of those later on in this article.

What to expect after reading this article on Computer Programming Business Requirements Analysis?

There is no shortage of methodologies, gurus, approaches and techniques today. Having said that, we will share our years of consults experience and wisdom and the data shows one main common denominator:

“All Information Technology organizations, peers, clients and users want is something they can use: today, with their clients, on budget and time. Something that works, that has worked, and will keep working. Safely and securely.”

I can say this, everything you learn here is guaranteed to solve all but the Safely and securely part. That’s a whole new topic.  However, in the analysis you must be able to identify possible security breach nodes or social engineering points, and other security risks. We will show you that using a case study approach. For security implementation, IT forensics, or if your network or website has been compromised / hacked then contact us.

We do have a strong emphasis on the client because they are the users of the system. A very misguided managerial move to bypass users from the process is the root cause of most restarts and failures and that equals higher cost.

 

“Measure twice cut once.”

We also focus on the management and employees in the business area being analyzed – the customers of our services. Since our mission, as IT professionals is to deliver the best to our customers we need to know who they are, and what they need.

“Quality is conformance to requirements.“

All this work can be done from any device using online services such as:

Google Docs Online – Because Microsoft dropped the ball asking for money then making it free limited.

draw.io Online – Best diagramming software for HTML interface. Flowcharts, DFDs data flow diagrams, and more.

Create a graph Online – For creating  graphs and charts like the ones in this article.

I use an Asus Chromebook, its safe, fast, 10 hours battery life and affordable. Why conduct business or do computer work with the ball and chain method?  Contact us to learn how to use your Chromebook as the interface to your laptop or desktop even remotely.

Analysis to Design

Analysis is not a rigid sequence of activities. It is an interactive process of communication between the clients and the analysts in which we construct a precise and concise model of the requirements of the business. What we mean by this is that, in analysis we want to discover and describe all of the information that the business requires and all of the ways that information can be used. Design is the progressive refinement of the Business Requirements Specification to include how these requirements are to be implemented. Typically design is seen as a transition from analysis, but we see it as a bridge from analysis to coding, where it is simply a further iteration of the business requirements specification. It should not be a translation effort but rather a seamless process of progressive refinements. A good representation of that is demonstrated in image below Analysis and Design:

Analysis and Design image:

Analysis and Design – Computer Programming Business Requirements Analysis

Key Concepts

Some key concepts in the SDLC process we will cover in this article are:

• Objectives
• Scenarios
• Constraints
• Data Flow Diagrams
• Entity Relationship Diagrams
• Data Items
• Relationships
• Objects
• Context Diagrams
• Activities

Scenarios:

A scenario describes a single path taken in the business process. We will discuss various uses for scenarios later on.

So let’s take Buying a WordPress Premium Package from MiltonMarketing.com website as an example of a business path:

1. 1. A potential client indicates a desire to finally get a custom website for their business. I mean it’s only 2019.
   2. MiltonMarketing.com rep provides the client with options and more information, or the client used website.
   3. The rep or website confirms client information. (register account, validate email.)
   4. The rep or PayPal authorizes the credit card. (Its valid.)
   5. The rep or PayPal record the details of the new registration.
   6. The rep will contact client to begin Requirements Analysis.

Objects and Data Items:

We will use Objects and Data Items, to describe the data that we will discover in our analysis. In structured Systems Analysis we call objects Entities. An object is a noun – a person, place or thing. In the scenarios example above for purchasing a WordPress Premium package from MiltonMarketing.com some of the objects that would be identified in this system would include:

1. 1. Client
   2. Rep (web expert)
   3. Package
   4. PayPal
   5. Location

Similar to an object, a data item is a noun; only this noun represents something we need to know about an Object.

See also: Object-Oriented Programming (OOP) to better understand objects terminology.

In Structured Systems Analysis, a data item is often called an Attribute. The object Client is described by related Data Items. see image below:

Sample Object & Related Data Items – Computer Programming Business Requirements Analysis

Entity Relationship Diagrams

We will carry this concept a lot further and find that using objects will help us in our understanding and organization of the data that we will need in describing the requirements of our system. In continuing with our description of the data that will be required in our system, we will use a tool called the Entity Relationship Diagram to illustrate how the data relate to each other.

Entity Relationship Diagrams – Computer Programming Business Requirements Analysis

Activities and Data Flow Diagrams

We use activities to describe functionality of the system and what will be required, in the activity, in order to support the users requirements. An activity, therefore, would be defined as a group of functions that must be performed in order for the business to operate successfully. We use data flow diagrams to model activities. The example in Scenarios about Buying a WordPress Premium Package from MiltonMarketing.com website some typical activities could include:

• • • Registering a user for buying a WordPress Premium package.
    • Receiving Payment for a WordPress Premium package.
    • Preparing a WordPress Premium package / demo.
    • Preparing a Schedule.

Once we have identified the activities, we will use a diagram tool called the data flow diagram, to graphically illustrate the activity and what goes on in it. (see image below)

Sample Data Flow Diagram for Buying a WordPress Premium package from MiltonMarketing.com website. – Computer Programming Business Requirements Analysis

In the image above notice how from the Client (Database) to the activity of Buying a WordPress Premium package labeled in red as: Client info confirmation (SECURITY)

The reason for this is because we need to be able to identify security threats from all possible nodes. One possible node is the database that holds all the client info. Any client info cannot be released, discussed or changed unless we verify the customer. Also identifying possible security risks in the requirements analysis helps your security experts later. Hence its labeling in the requirements analysis. Perhaps a SME (Subject Matter Expert) on security is required.

Methods for Gathering Requirements

When you finish reading methods for gathering requirements you should be able to:

• Understand various methods for gathering requirements
• Understand the advantage of gathering requirements directly from the clients and users.
• Understand the advantage of a Requirements Discovery Session.
• Plan a Requirements Discovery Session.

Requirements Elicitation Practices.

There are numerous methods for gathering the requirements for a project. The method you employ will depend on which is best at getting the requirements done correctly, accurately, and with least cost, and which fits the company, client project, best. Options in order of increasing effectiveness are:

• • • Don’t do requirements at all
      • Pros: None.
      • Cons: If you are not talking to the client or users, how do you know you have their requirements? If you do not define requirements there is little or no chance of meeting the customers needs and expectations. Not doing requirements analysis upfront only postpones the inevitable and usually results in numerous review meetings, design rework, and extensive testing. If we do not have any documentation of customer needs, what do you base acceptance on?
    • Questionnaires
      • Pros: The requirements are based on the clients responses.
      • Cons: It is, however, one-way communication. The answers can only be as good as the questions asked. Because the questionnaires need to be collated, summarized, and any conflicts and inconsistencies resolved, there is usually a lot of guesswork and inference that is made by the analyst or designer resulting in a biased solution or design. There is also a large effort required to prepare, distribute, consolidate, and report.
    • Interviews and/or meetings
      • Pros: Direct interviews and meetings (communication) is being made with the client and users of the system. In some organizations, the meetings may be by teleconference, because of wide geographic locations. These meetings are not as effective as face-to-face meetings, but are certainly superior to questionnaires.
      • Cons: Unfortunately there is usually little structure to the interviews; they end up revisiting, repeating, and reviewing specs. It is exceedingly difficult to coordinate resources and schedule people’s time – especially if users have been asked and have attended numerous similar meetings with mixed or poor results. The analyst may find it very difficult to obtain the time commitment for the number of meetings with different user communities and business areas are required, there will definitely be a significant, time-consuming and difficult effort required consolidating potentially conflicting results.
    • A Requirements Discovery Session(RDS)
      • Pros: A Requirements Discovery Session (RDS) is an interactive session with key business representatives, also known as Subject Matter Experts (SME). The advantage of the RDS is that it brings together in a common setting the necessary SME’s to productively elicit and gain consensus and agreement to the requirements. It is conducted by a skilled analyst/facilitator. It defines and documents requirements in real-time, often producing a deliverable during or at the end of the meeting for immediate review. And it applies best business requirement practices.
      • Cons: Users must be prepared to commit the time necessary to attend the discovery sessions and it may be difficult to obtain that time commitment.

The Requirements Discovery Session

Interactive session with key business representatives.

A typical session might involve anywhere between two and twenty business managers and users. These participants can range from senior business managers to the system users – depending on the type of project and scope of the system.

Forum for gathering of clients business requirements.

Better than any other technique, the Discovery Session (RDS) creates an environment of open discussion that identifies a consensus of the requirements from a broad range of parties.

Conducted by a skilled analyst / facilitator.

A formal Requirements Discovery Session (RDS) is lead by an analyst who facilitates the session by asking the questions of the business clients in order to develop the Business Requirements Specification.

Defines and documents requirements.

During the session, the client’s requirements are captured right away – in their own words. This enables a deliverable to be produced immediately for review and distribution to all interested parties (management, consultants, systems analysts, vendors, etc.)

Applies the best business requirements practices

The session is conducted using models that are proven to be effective – that are understandable by the clients – resulting in a positive, productive experience.

Advantages of a Requirements Discovery Session

• Applies best practices in modeling the requirements
• Keeps the group focused and on track
• Uses business language rather than technical terms
• Clarifies ambiguities and resolves misperceptions by dealing directly with the client users
• Focuses on the clients’ business and project objectives – on new requirements vs. the current system
• Applies the principle of conducting analysis before designing the system
• Identifies what is needed before designing how it is to be done
• Focuses on questions that elicit needs vs. haves
• Employs an iterative process that builds successively to completion.

Planning for a Discovery Session

Scheduling and holding a discovery session involves concerted planning and careful preparation to ensure a successful and productive meeting.

Pre-Session Activities

• • Select a pilot project
  • Hold a scoping meeting
  • Obtain project objectives and background
  • Set expectations of the discovery process with the users
  • Plan and schedule appropriate facilities and meeting logistics.

The team members

• • A facilitator who runs the meeting
  • A requirements Architect who is responsible for the document and deliverables
  • Core Subject Matter Experts (SME)
  • Project Manager(s)
  • Observers (non-participating)
  • Representative(s) of the project sponsor who has (have) decision-making authority where this project is concerned.

The schedule

• • An individual Requirements Discovery Session could take anywhere from 1/2 day (for a very small project – maybe a maintenance or enhancement project) to a three or five-day session depending upon the size of the project. Larger projects may hold multiple sessions for different business areas or processes
  • Explain the process (high level familiarization, not education)
  • Review the agenda
  • Platoon SME’s as required by functional areas.

The forum

• • Highly interactive with the facilitator guiding the process
  • Requirements Architect will also provide guidance
  • Apply the Best Business Requirements Practices (taught in this article.)
  • Apply your meeting and facilitation skills
  • Business focus, not techno mumbo jumbo babble.

The Deliverable

• • Produce interim review documents at points during the session
  • Produce a working copy of the Business Requirements Specification at the end of the session with Client’s comments included.

Tips and Guidelines for Holding an RDS (Requirements Discovery Session)

• • Prepare for your meetings (plan)
  • Always build on the information already gathered
  • Plan for meetings to validate findings
  • Don’t let too much time laps between meetings
  • Follow The Discovery Process taught by this article.

Describing System Objectives and Scope

We will discuss the analysis activity of describing the objectives and scope of the project and/or system. We will define what is meant by objectives and scope and introduce some models that can be used to assist in this effort. We will discuss when this activity should be done in the system development life cycle and more specifically, when in the process of requirements analysis. You will also be introduced to a number of different techniques that can be used to describe objectives and scope interactively with the client management, users, and subject matter experts. You will see in detail, steps to take, models to use, and questions you can ask to help you, as an IT professional, ensure that you are getting your requirements effort off to a productive and successful start.

Why is this important?

The reason for describing objectives and scope is to establish clarity and consensus of purpose, and to establish boundaries for the analysis process. This process will also assist in providing a starting point for beginning the requirements gathering process.

• • • We must know where we are going?
    • Why?
    • and what are we trying to achieve?
    • What is it going to look like when we are done?
    • What will we have achieved?
    • What are the goals and objectives of this project or system?

Another critical intention of this first activity of the requirements discovery process is to identify

If you are learning and enjoying our free content please buy us a cup of coffee…to be continued….

Related Posts:

Home

My little pony learning game in VB.NET

The Guide to Ethical Hacking

Paginate Your WordPress Site Without Plugins

How to secure your Nest account and cameras and keep hackers at bay

Designing an app in Pseudo code

Object-Oriented Programming (OOP)

Systematic approach to Problem Solving

Methods of teaching programming

Google’s “Grasshopper” Mobile Game Teaches Adults How To Code In An Easy, Accessible Way — And It’s Free

CSS, HTML, JAVASCRIPT, Online Compiler. Code on the go by replit.it

Computer Science Curriculum From Minecraft

Doomsday Docker security hole uncovered

Building a web page with HTML tags

Introduction to JavaScript – Control Flow: if/else Statements

Where automotive cyber security is headed

Products and Services

U.S. Govt Issues Microsoft Office 365 Security Best Practices(Opens in a new browser tab)

Networking The Complete Reference, Third Edition(Opens in a new browser tab)

AI machine learning and deep learning: Everything you need to know(Opens in a new browser tab)