Requirements Analysis (BABOK KA)

May 13, 2018
2161 Views
16 Likes
0 Comments
Naturally, us Business Analysts are facilitators, whether we're running workshops or holding stakeholder meetings, we're always the ones engaging with people. And it should really be no different for the running of a Design Sprint; use your best facilitating skills to lead the Design Sprint and make it a really good week for everyone involved! In addition to hosting over the five days, you should consider yourself responsible for reporting on the outcomes of the week to stakeholders, this will include making a decision on what to suggest taking forward as an idea and what should simply be forgotten about.
Feb 11, 2018
5406 Views
8 Likes
0 Comments

Since 2009 we have enjoyed reflecting on what’s happened the previous year on projects and making predictions for the upcoming year. Here are some of the recent trends we have discussed: agile successes and challenges, recognize the importance of roles that help maximize value, Scaling Agile, Certification trends in business analysis, etc...

Here are the seven industry trends that we have chosen for 2018.

Jan 21, 2018
6516 Views
8 Likes
0 Comments

Intelligent Business Requirements are business needs and objectives that were designed to add business value and promote scalability and innovation.

‘Project success’ is the attainment of predefined criteria that emerge from attainment of user requirements. User requirements, in turn, are defined by an evaluation of the business and functional requirements. Thus requirements pave the path that leads to project success.

Dec 17, 2017
6209 Views
8 Likes
1 Comments
I don’t know how many articles I’ve read where the author states requirements should be “what” the user/client needs, not “how” to deliver the solution. They say “A requirement should never specify aspects of physical design, implementation decisions or system architecture”... In my humble opinion, every requirement, even the business level needs, goals and objectives, are just the start of a long march to a solution.
7228 Views
9 Likes
1 Comments

Scope creep (also known as feature creep, requirements creep, featuritis, and creeping featurism), however, refers to the uncontrolled growth of functionality that the team attempts to stuff into an already-full project box. It doesn’t all fit. The continuing churn and expansion of the requirements, coupled with inadequate prioritization, makes it difficult to deliver the most important functionality on schedule. This demand for ever-increasing functionality leads to delays, quality problems, and misdirected energy.  Scope creep is one of the most pervasive challenges of software development. 

 

Jul 17, 2017
5761 Views
5 Likes
0 Comments
When security requirements are considered at all during the system life cycle, they tend to be general lists of security features such as password protection, firewalls, virus detection tools, and the like. These are, in fact, not security requirements at all but rather implementation mechanisms that are intended to satisfy unstated requirements, such as authenticated access. As a result, security requirements that are specific to the system and that provide for protection of essential services and assets are often neglected. In addition, the attacker perspective is not considered, with the result that security requirements, when they exist, are likely to be incomplete. We believe that a systematic approach to security requirements engineering will help to avoid the problem of generic lists of features and to take into account the attacker perspective. Several approaches to security requirements engineering are described here and references are provided for additional material that can help you ensure that your products effectively meet security requirements.
Jun 11, 2017
7680 Views
9 Likes
0 Comments
The purpose of this brief article is to explain the connection between documenting requirements and contract type. Recently I consulted with a firm eliciting requirements for a new product. In this case, an internal business analyst team was documenting the product requirements by consulting with appropriate stakeholders. The follow-on project intent was to outsource the work to develop the product in the form of a contract.
May 21, 2017
11372 Views
23 Likes
2 Comments
I bet everyone has, at least once in their career, heard the expression:

“We don’t need any up-front analysis: I already know what I want!”

Often these words are followed by a description of a specific type of solution, often an IT system, and often a specific vendor name. Perhaps our executive stakeholder has decided they need to migrate onto the newest platform, the organization needs a new ‘mobile app’, or we need to ‘move all of our data into the cloud’. I can imagine some people will be holding their heads in their hands as they read this paragraph…

May 13, 2017
10246 Views
4 Likes
0 Comments

iRise gives Business Analysts the tools they need to communicate clearly with both the business and its stakeholders.  They use working previews that can be virtually indistinguishable from the final product.  When business analysts uses iRise to elicit and document requirements: the business analyst becomes a powerful weapon to get to the right answer, ...

Apr 17, 2017
8595 Views
16 Likes
1 Comments

We hit a challenge however when we attempt to promote the value of Business Analysis to IT Management or the Business...  The reality is that simply promoting “better requirements” does not sell our value-add in terms that management from an IT or Business perspective understands... So how do we do this? Let me share five lessons learned based on my experience as a senior requirements management consultant. 

Mar 29, 2017
6926 Views
7 Likes
0 Comments

A common challenge of enterprise Business Analysts is the discovery, understanding, and description of requirements in the context of implementing packaged solutions. Management assigns us to projects with a predefined solution, and we struggle to figure our role when there seems to be no significant build activity. What are we supposed to do in this situation when there seems to be no need to produce standard requirement deliverables?

 

Put a typical Business Analyst in this environment and do not be surprised to hear the phrase “I’m not sure of my role.” Why do packaged solution projects cause discomfort?

Mar 19, 2017
17110 Views
15 Likes
0 Comments

A business analyst is a person who analyzes, organizes, explores, scrutinizes and investigates an organization and documents its business and also assesses the business model and integrates the whole organization with modern technology. The Business Analyst role is mostly about documenting, verifying, recording and gathering the business requirements and its role is mostly associated with the information technology industry.

11685 Views
79 Likes
2 Comments

The difficulty of gathering information and establishing requirements, owing to the chaotic nature of the business world, is clear to see. Every business analyst must overcome their own Mad Tea Party if they are to be successful in carrying out their mission. As Alice is confronted with the unreliability of the Hatter, the March Hare, and the Dormouse, so too is the analyst faced with unreliable stakeholders. In her attempts to gain an understanding of the never-ending tea party, Alice’s use of elicitation is effectively useless in the face of endless riddles, an unconventional sense of time, and undependable characters.  Analysts find themselves in comparable environments with various degrees of chaos and unpredictability. 

10946 Views
70 Likes
0 Comments
We implemented A/B testing into our product 6 months ago. During that time we conducted a variety of A/B tests to generate insights about our user's behaviour. We learnt a lot about our specific product. More generally, we learnt about how to run valuable A/B tests.
12561 Views
69 Likes
0 Comments

Most discussions about software requirements deal with business information systems and similar projects. The world is also full of products that use software to control hardware devices, broadly called embedded systems. Among countless examples are cell phones, television remote controls, kiosks of all sorts, Internet routers, and robot cars.  This is the first article of two that will discuss some of the requirements issues that are especially important to embedded and other real-time systems.

Page 1 of 10First   Previous   [1]  2  3  4  5  6  7  8  9  10  Next   Last   




Latest Articles

Make your work visible
May 22, 2018
0 Comments
When speaking to a business analyst on a busy project, I am often told that ‘at the end of a working day, I feel like I have achieved nothing&rs...

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC