10315 Views
4 Likes
0 Comments
Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains. The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the r...
4732 Views
0 Likes
0 Comments
This article, actually a compilation of three articles, provides proven advice for applying agile strategies on IBM® Rational® Unified Process®, or RUP®, teams. The articles are written by Mark Lines, Joshua Barnes, and Julian Holmes respectively, co-founders of Unified Process Mentors (www.upmentors.com). These three have mentored literally thousa...
9631 Views
1 Likes
0 Comments
There are three basic reasons why you might need to model a business: to re-engineer a business, to improve a business process and to automate a business process. Nevertheless, another reason may be very useful for analyst of software systems and their customers – to understand and automatically generate functional requirements to the system. ...
8258 Views
3 Likes
0 Comments
First, I'm a project focused software developer, team lead, designer, architect, jack of all trades, who has been on projects that have used various methodologies over the years, including of late some agile projects. I'm not a big blog reader, or a big blogger, but like most people I have an opinion on things, and for some reason that opinio...
3489 Views
1 Likes
0 Comments
Agile software developers, just like traditional software developers, perform analysis activities. Unlike traditional developers, agilists approach analysis in a highly collaborative manner and do so on a just-in-time (JIT) basis. Analysis is so important to us we do it every single day. In this article, I discuss: What is analysis? Ret...
3607 Views
1 Likes
0 Comments
In this issue of the IIBA Newsletter: IIBA Blog Spotlight As the IIBA is a virtual organization, the Blog is an integral way for the Senior Leadership Team (SLT) to communicate with members worldwide. The topics range widely: from technical pieces such as BABOK® updates to more informal pieces like “A day in the life…” 2008 CBAP Exam Dates Date...
8042 Views
0 Likes
0 Comments

My friends and colleagues often ask me how I am able to produce so much in so little time.  Although I am flattered by such compliments, it's really not much of a secret which I attribute to the following areas (in no particular order):...

Author: Tim Bryce

5954 Views
0 Likes
0 Comments
A project manager's first task after being appointed to an IT development is to seek out a business analyst to gather requirements. After that, it's on to the development and then the implementation. It's the way it's done. It's the way it's always been done. But business analysts are not used optimally if they are only used to "gather" require...
12180 Views
2 Likes
1 Comments

Have you noticed the examples of requirements elicitation on my blog? In one case, I had a bit of a contest, using a game to elicit information. You can see this technique by looking in the category Online Game on the blog. Then I had a survey to elicit information. You can see that survey by looking in the category Survey on the blog. Today I am going to use the information from the survey to show you another technique you might use when developing requirements. That technique is writing Personas (or Personae for you Latin fans).

You write a Persona when you want to understand your customers better. This Persona is a story you will tell about a typical (but not real) customer. The Persona is a composite story about your typical customers, made very lifelike.

4420 Views
0 Likes
0 Comments
Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increas...
4775 Views
0 Likes
0 Comments
IAG Consulting’s new Business Analysis Benchmark makes one thing clear: almost 70 percent of companies surveyed set themselves up for both failure and significantly higher cost in their use of poor requirements practices. That failure came at a significant cost: the average $3 million project cost companies using poor requirements practices an aver...
10384 Views
11 Likes
0 Comments
UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes. Class diagrams are typically used, although not all at once, to: Explore domain concepts in the form of a domain model Analyze requirements in the form of a conceptual/analysis model Depict the detailed de...
10733 Views
0 Likes
0 Comments
UML 2 class diagrams are the mainstay of object-oriented analysis and design. UML 2 class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. Class diagrams are used for a wide variety of purposes, including both conceptual/domain ...
25236 Views
2 Likes
0 Comments

THE ANALYST (aka, Systems Analyst, Systems Engineer, Systems Architect, Business Analyst) - requires specifications about the end-User's information requirements in order to design a system solution.  This is normally based on a definition of the user's business actions and/or decisions to be supported.  Following the system design, the Analyst produces the specifications required by the Programmer and DBA to fulfill their part of the puzzle.  From this perspective, the Analyst is the translator between the end-User and the Programmers and DBAs.

Each party has his own unique perspective of the puzzle and, as such, requires different "specifications."  To compound the problem though, the role of the Analyst sharply diminished over the years, leaving it to the Programmers to try and determine what the end-User needs, a skill they are typically not trained or suited for. 

14144 Views
6 Likes
0 Comments
To communicate or not to communicate? There is no question. As individuals and as organizations, we are constantly communicating — whether intentionally or unintentionally. The real question becomes whether we choose to effectively communicate or risk the high cost of miscommunication. The cost of miscommunication can take many forms, including but...
Page 74 of 83First   Previous   69  70  71  72  73  [74]  75  76  77  78  Next   Last   

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC