00:16i'm tom hathaway and i am currently
00:19at so let's talk business analysis
00:23in this nugget we're going to talk about
00:26what requirements are what flavors they
00:29and how that knowledge is going to help
00:31you when you are the one wearing the ba
00:35what is a requirement in the world of
00:39a requirement defines a feature that a
00:43has to enable such as cloud access
00:47a function that a future solution has to
00:50like calculate savings
00:54a fact that a future solution has to
01:00or a quality that a future solution has
01:05as in access to a file in one second
01:09requirements are the foundation upon
01:11which information systems are built
01:13and just like a building if the
01:16foundation is not solid
01:17the building will not stand
01:20fundamentally a requirement is how we
01:22communicate with the builders or buyers
01:25of the solution need to build or buy
01:28this gets us fully into the world of
01:32with all its misunderstandings
01:34misinterpretations and
01:35misrepresentations finally
01:38what requirements are depends to some
01:40degree on the software development
01:43or sdm that your organization uses
01:46and where in the development life cycle
01:50in an agile sdm requirements are
01:53fundamentally negotiable
01:55whereas in a traditional waterfall or
01:58sdm changes are only allowed within a
02:01rigorous change management process
02:04to reduce the problems of communication
02:06between those who want a solution
02:08and those who can provide it the
02:10international institute for business
02:13or iiba in its business analysis body of
02:18babak defines four fundamental types of
02:22requirements business requirements
02:25define the goals and objectives that the
02:26organization as a whole
02:28strives to achieve stakeholder
02:31requirements are the specific needs and
02:34or individuals within the organization
02:38solution requirements are the functions
02:40and qualities that a solution has to
02:43to be accepted transition requirements
02:46define attributes and actions necessary
02:48to implement the new solution
02:50in the existing organization as you can
02:53each type of requirement expresses a
02:55different level of detail
02:57business requirements are very high
02:59level and a typical project will address
03:03business requirements beget stakeholder
03:05requirements we get solution
03:08a typical project needs many stakeholder
03:11to specify the business requirements
03:13from the perspective of the people
03:16solution requirements turn the focus of
03:18the stakeholder requirements toward the
03:22there can be a very large number of
03:24solution requirements
03:26finally transition requirements define
03:28components of the solution
03:30that only exist to replace the current
03:32solution as it exists today
03:35let's look at each type in more detail
03:38business requirements define high level
03:40goals and objectives of an organization
03:43and address the question why is this
03:47the executive level within the
03:49organization usually defines the
03:50business requirements
03:52their primary purpose is to prioritize
03:59simple sentences potentially with
04:01collaborating explanations and
04:04charts and diagrams are the preferred
04:06modes for expressing business
04:10in an agile environment they may be
04:14features or user stories
04:17the default recommended structure for a
04:20good business requirement
04:21textual statement follows the mold
04:24to achieve a business outcome
04:27the organization or a group within
04:30need want will should do something
04:35for example to maintain our leadership
04:38role within the industry
04:39be a expert needs to increase gross
04:43by 15 this fiscal year
04:47or to increase our customer retention
04:50the claims department needs to reduce
04:52claims processing time
04:54from 10 days to four days by the end of
04:57quarter stakeholder requirements express
05:01the needs and wants of one or more
05:04and how they will interact with a
05:07stakeholder requirements bridge business
05:09and solution requirements
05:11interviews joint requirements planning
05:15and user story workshops are common
05:19stakeholder requirements which should be
05:21self-authored by the various
05:24ideally stakeholder requirements limit
05:27premature technology decisions
05:29meaning they express what is needed not
05:32how it will be achieved
05:35some exceptions apply for instance if
05:37the goal of the project is to migrate
05:39functionality to a website
05:41the use of terms such as online via the
05:46are acceptable stakeholder requirements
05:50can be expressed as simple statements
05:52spreadsheets user views models
05:56epics slash user stories business use
06:01workflows etc with or without
06:04models or diagrams a commonly used
06:07structure for a simple
06:08textual stakeholder requirement has
06:11evolved into a format known as a
06:13user story although user stories
06:16originated in an agile sdm
06:18they have proven to be valuable for any
06:23they follow the format as a stakeholder
06:27i or we can or cannot
06:31do know or have something
06:34to achieve my goal or objective
06:38for example as a customer i can browse
06:41the current product catalog to select
06:43items that i want to buy
06:48another example as a website visitor
06:51i can view the cost of coverage for each
06:55to select the cheapest note that this
06:58structure assumes that the proposed
07:00already exists solution requirements
07:04describe specific characteristics of a
07:07that meet business and stakeholder
07:09requirements and come in two flavors
07:12solution functional requirements define
07:15what the solution has to do
07:17or know solution quality requirements
07:20more commonly albeit misleading
07:23non-functional requirements
07:26define characteristics that any solution
07:28must exhibit for it to be acceptable
07:31the most common sources of solution
07:34are the analysis of business and
07:36stakeholder requirements
07:38analysis of existing i.t systems and
07:41associated stakeholder interviews
07:44including in particular here
07:45the it group common examples for
07:49expressing functional solution
07:51are lists of functions typically in verb
07:56solution use cases detailed user stories
08:00lists of data elements prototypes or
08:03mockups of user views
08:05process diagrams data models activity
08:09class models etc because the solution
08:13requirements are close to the technology
08:16the representation should be easy for
08:18the developers to use
08:21typical functional solution requirements
08:24the steps of a process including
08:27decisions alternatives exceptions and
08:32i.e calculate total charges including
08:34delivery costs and taxes
08:38business rules including calculations
08:41authority levels and event responses i.e
08:45do not ship goods to customers with
08:49business data components including user
08:52relationships and metadata the monthly
08:58the most common form for expressing
09:01requirements are complete simple
09:04describing a quality in measurable terms
09:09typical quality solution requirements
09:12legal requirements service level
09:16contractual obligations audit
09:20internationalization requirements
09:24reliability availability throughput
09:26maintainability flexibility scalability
09:29portability and usability
09:32transition requirements describe
09:34capabilities needed to integrate the
09:37into the existing environment they
09:39described capabilities that the solution
09:42to facilitate getting from the as is to
09:45to be but will not be needed once the
09:48new solution is in production
09:51initially defined in complete sentences
09:53other viable forms for expressing
09:56transition requirements are interfaces
09:59database conversions workflow designs
10:02process models data models job
10:07training programs and job aids
10:11a thorough understanding of the selected
10:13solution and of the current environment
10:16ultimately dictates the transition
10:20this implies that it is impossible to
10:22finalize the transition requirements
10:24before the design of the selected
10:26solution is complete
10:29examples of transition requirements are
10:32sales personnel must attend the two-day
10:33new customer acquisition program
10:36prior to using the new sales support
10:40all existing customer data will be
10:42maintained in both the old and the new
10:45until the end of the first quarter all
10:48four levels of requirements create a
10:50complete picture of the solution
10:52that both the business community and the
10:54developer community can understand
10:57as you see here business requirements
10:59lead to stakeholder requirements lead to
11:01solution requirements
11:02lead to transition requirements
11:05interestingly the picture also
11:07that the transition requirements
11:09actually feed into the new business
11:12this typifies the fact that the business
11:14changes once the new solution is in use
11:17this change will have an impact on
11:19future business requirements
11:21based on the new situation in addition
11:24the picture illustrates the risk of
11:26missing any particular category of
11:29if you remove one category of
11:30requirements the ensuing gap represents
11:34to the success of the project
11:37this does not imply that the number of
11:39requirements has to be enormous for the
11:43the volume of requirements has to be
11:45right at the right time
11:47for the size and complexity of the
11:51depends heavily on the level of detail
11:55the level of detail is a question of
11:57timing in an agile sdm
12:00details are discussed incrementally as
12:04while in a traditional sdm they are
12:06captured in the requirements definition
12:09during the analysis phase of the project
12:13nonetheless the buy-in and understanding
12:16all requirements by the appropriate
12:19at a sufficient level of detail is
12:22crucial to implementing
12:27as you can now appreciate the ultimate
12:29answer to the question
12:31what is a requirement is that it is
