Requirements Management and Communication (BABOK KA)

27703 Views
19 Likes
0 Comments
Every software team talks about project scope and team members often complain about unending scope creep. Unfortunately, the software industry lacks uniform definitions of these terms, and the requirements literature is short on clear guidance regarding how to even represent scope. I confront scope head-on in this series of three articles...
13062 Views
0 Likes
0 Comments

Are the current IT systems meet the requirements of Business users or deliver the services that will bring competitive advantage to the organizations?

IT projects continuing to cost overrun, time overrun or doesn’t meet requirements. Poor communication – particularly between business and technical experts – is a constant problem. – As per Financial Times

16296 Views
9 Likes
3 Comments

Many business analysts focus their full attention on tasks related to specifying, modeling, verifying, and validating requirements. And in doing so, they often forget about a critically important aspect of the BA work:requirements prioritization... Since good prioritizing skills help teams deliver business value faster, it’s a key competency for business analysts to develop. An effective to get better at prioritizing requirements is to follow this 3-step approach during the requirements discovery process.

15203 Views
3 Likes
4 Comments

Business Requirements are central to Software Development Offshoring relationship. Requirements are not hard objects that can be put across as formulas or equations. Irrespective of the artifacts used in requirements communication, requirements remain soft objects subject to various interpretations that may leave many voids for assumptions.

The purpose of this article is to investigate the challenges of requirements communication in Software Development projects.

18104 Views
33 Likes
8 Comments

It’s always the requirements fault! Whenever anything goes wrong with a software development project the requirements tend to be the scapegoat. It is a fact of life as a BA that at some point the requirements you write will be wrongly blamed for a mistake in the product. In reality, any oversight in the product is the responsibility of the entire development team. So what can the BA do to ensure they are not the convenient scapegoat for an issue with the product?

16540 Views
5 Likes
1 Comments

This article discusses a tool for documenting, categorizing, ranking and decomposing various types of requirements (business/user and solution).  The business analyst (BA) can use this tool to capture high-level business and user requirements and then decompose them into solution requirements. In fact, the tool can be used multiple times and results strung together to provide forward and backward traceability of requirements through specification and test cases. 

70893 Views
34 Likes
0 Comments

Large software systems have a few hundred to thousands of requirements. Neither are all requirements equal nor do the implementation teams have resources to implement all the documented requirements. There are several constraints such as limited resources, budgetary constraints, time crunch, feasibility, etc., which brings in the need to prioritize requirements.

16271 Views
3 Likes
0 Comments

 Managers often ask me what return on investment (ROI) they can expect from the money they spend on training, process improvement, and tools for requirements engineering. I’d love to give them a nice, tidy answer—but I can’t. As with so many questions in software, the correct answer is, “It depends.” This article explores some of the factors that influence what ROI an organization can expect from better requirements.

17803 Views
6 Likes
0 Comments
In this article we discuss the benefits of using an appropriate template as the vehicle for delivering requirements. We also cover how a review and approval process tailored to stakeholders can help create the alignment needed to move a project forward.
62657 Views
42 Likes
0 Comments
The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team.
17728 Views
6 Likes
0 Comments

Software developers often want to freeze the requirements following some initial requirements work and then proceed with development, unencumbered with those pesky changes. This is the classic waterfall paradigm. It doesn't work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline. This article defines the requirements baseline and describes when to create one.

 
English (auto-detected) » English
 
 
English (auto-detected) » English
 
 
English (auto-detected) » English
 
19941 Views
4 Likes
0 Comments
This is the tenth in a series that explains the thinking behind the Volere [1] requirements techniques—previous and future articles explore aspects of applying these techniques in your environment. This article illustrates how the requirements travel all the way through an organisation – and beyond - and how everyone is interested in/affected by them but all for different reasons.
17833 Views
13 Likes
4 Comments

You can now create an instant app from your schema, and add spreadsheet-like expressions for business logic – a complete system in minutes. In this article, we review a new technology from Espresso Logic that makes your requirements – schemas and logic - into working software, and show an example of building a full application from scratch.

28040 Views
25 Likes
4 Comments

Tracking project status means comparing where you really are at a particular time against the expectation of what “complete” means for this development cycle.  Monitor the status of just those functional requirements that were committed for the current release, because that’s the set that’s supposed to be 100 percent done before you declare success and ship the release.

31665 Views
23 Likes
0 Comments

How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer.

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

 



 




Copyright 2006-2021 by Modern Analyst Media LLC