4533 Views
0 Likes
0 Comments
Many organizations are scratching their collective heads over how to build and mature a business analysis center of excellence (COE). Where do we start? What does a business analysis center of excellence look like? Who owns it? How does it evolve? This white paper outlines the standard operating practices necessary for a business analysis center o...
5144 Views
1 Likes
0 Comments
Be it explicitly or not, someone always performs the role of requirements analyst on a software project. The official title may be requirements engineer, business analyst, system analyst, product manager, or simply analyst , but someone needs to translate multiple perspectives into a requirements specification and communicate with other stakeholder...
5106 Views
1 Likes
0 Comments
Given a specific project with a reasonably defined charter and clear business goals you, the business analyst, set out to elicit and document the detailed business requirements. So when do you stop? How do you know when you are done gathering the requirements?
3358 Views
1 Likes
0 Comments
Traditional software development has always required a long requirements-gathering phase at the beginning of a project that, if not handled correctly, can often result in schedule delays and costly budget overruns that have a significant impact on the project itself.  Software simulation can streamline that process and prevent many of the erro...
3671 Views
0 Likes
0 Comments
In this issue of the IIBA Newsletter: Base Consulting and Management Inc. Provides Financial Guidance by Shannon Bott BABOK Update by Kevin Brenan Experiencing the CBAP—Pre- and Post-Exam by Shirley Sartin
3384 Views
0 Likes
1 Comments
Many of the characteristics of properly specified requirements have been well known for many years, at least among professional requirements engineers. Yet most requirements specifications seen today in industry still include many poor-quality requirements. Far too many requirements are ambiguous, incomplete, inconsistent, incorrect, infeasible, un...
3034 Views
1 Likes
0 Comments
Maybe it was that southern drawl. Or maybe it was because I got mad. I'm not sure why I still remember this moment so clearly, but I do.  It happened when I was at Spyglass, over ten years ago.  Several of us developers were in a meeting with Steve Stone, then recently-hired as director of the Champaign office.  We were talking abo...
11666 Views
10 Likes
0 Comments
In this article, the focus shifts to a particular view in the 4+1 Architecture Views, defined by the Rational Unified Process. We will examine how to use Activity Diagrams as "roadmaps" for the Process View, to capture processing flows as a series of steps. We will also discuss several techniques for creating these diagrams and ensuring their effec...
7276 Views
2 Likes
0 Comments
The core purpose of software development is to provide solutions to customers' real problems. Use cases are a vital aspect of a technique that has been used successfully to ensure that development projects actually focus on these problems. They are used to discover, capture, and present customer requirements in a form that is accessible to develope...
13278 Views
5 Likes
0 Comments
The author illustrates how to use UML Activity Diagrams to capture and communicate the details of user interface navigation and functionality, and explain three stereotypes: presentation, exception, and connector. Author: Ben Lieberman
4277 Views
0 Likes
0 Comments
In this issue of the IIBA Newsletter: Memoir of the CBAP Exam by Chip Schwartz One Test-Taker’s Thoughts on the CBAP’s Value and Lengthy Application by Diana Cagle New Sponsorship Program by Liz Hadland Springtime Chapter News by Glenn Bule
4908 Views
0 Likes
0 Comments
In this column, I summarize the 12 worst of the most common requirements engineering problems I have observed over many years working on and with real projects as a requirements engineer, consultant, trainer, and evaluator. I also list the negative consequences of these problems, and most importantly suggest some industry best practices that can he...
7048 Views
12 Likes
0 Comments
Many managers and others who are not professional requirements engineers tend to greatly over-simplify requirements engineering (RE). Based on their observations that requirements specifications primarily contain narrative English textual statements of individual requirements and that all members of the engineering team are reasonably literate, the...
5055 Views
0 Likes
0 Comments
The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example login to system, register with system and create order are all Use Cases. Each Use Case has a description which ...
5881 Views
2 Likes
0 Comments
In this fourth and final part of the series I'll share some of my advice for writing good specs. The biggest complaint you'll hear from teams that do write specs is that "nobody reads them." When nobody reads specs, the people who write them tend to get a little bit cynical. It's like the old Dilbert cartoon in which engineers use stacks of 4-inc...
Page 65 of 66First   Previous   57  58  59  60  61  62  63  64  [65]  66  Next   Last   




Latest Articles

Requirement Elicitation: Stories Are Not Requirements
Mar 17, 2019
0 Comments
  One of the three activities encompassed under Requirements Analysis is the process of ‘ Requirements elicitation’. IIBA’s de...

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