Entries for the 'Systems Analysis' Category

(1885 Views) (1 Comments)

A Promise to have a Conversation I’ve been writing user stories for a couple of years now, and the best way I’ve heard how to describe them is that they are a promise to have a conversation. Enough information should be written down to give the reader an idea of what the gist of the story is (and to be able to roughly estimate a story point ...

Posted by: Seilevel

» Abandon the use of Non Functional Requirements

(5685 Views) (5 Comments)

This model is provided by Don Firesmith of SEI. Note the lack of an NFR category. More

Posted by: Craig Brown

» Agile Business Analysis using UML

(3494 Views) (1 Comments)

Following the lead of another forum, where the question was asked about the use of UML by Business Analysts, I would like to ask the same question when we come to Agile Analysis. The answer is NOT simple and like all professional questions needs analysis. This means, I shall post a series of these blog pages, expanding one point at a time. I will ...

Posted by: Gil

» Invest in User Stories

(2236 Views) (0 Comments)

User stories have a place in modern requirements management. They may not be going to replace use cases but you shoulod know how to write them well. Invest In Good User Stories View SlideShare presentation or Upload your own. (tags: agile scrum)

Posted by: Craig Brown

» How to write Entity Relationship Diagrams

(5348 Views) (0 Comments)

E R Diagram View SlideShare presentation or Upload your own. (tags: er diagram)

Posted by: Craig Brown

» Cascade - that's all 13 Principles of mine: do you have any? win a free copy of my book.

(1125 Views) (0 Comments)

Thirteen is all you need, at least in this point in time. I may add to them as time goes by, but I would also like to hear from readers if they have any suggestions or thoughts or their very own principles for IT Projects success. Pleae offer them and maybe we can get them into the second edition of the book...which you all remember is available at...

Posted by: David Wright

» Cascade Day 15 - Principle #13: Use Architecture to Manage and Integrate the Deliverables

(873 Views) (0 Comments)

13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system. This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assemble...

Posted by: David Wright

» Cascade Day 14 - Principle #12: Parcel work into two-week periods

(910 Views) (0 Comments)

12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire proje...

Posted by: David Wright

» Cascade Day 13 - Principle #11: Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change

(884 Views) (0 Comments)

#11. Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc. I was lucky to learn this early in the 90's as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools wer...

Posted by: David Wright

» Cascade Day 12 - Principle #10: Models are better than text

(889 Views) (0 Comments)

#10. Models are better than text. I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT). I must offer my respect to the many talented people who labored to produ...

Posted by: David Wright

» Cascade Day 11 - Principle #9: Leave a record of what you have done, so the project will not miss you if you leave

(908 Views) (0 Comments)

#9. Leave a record of what you have done, so the project will not miss you if you leave. If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in...

Posted by: David Wright

» Cascade Day 10 - Principle #8: It’s the Deliverable (that matters), not the Task

(936 Views) (0 Comments)

#8 --> It’s the Deliverable (that matters), not the Task. The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effec...

Posted by: David Wright

» Cascade Day 9 - Principle #7: One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

(992 Views) (0 Comments)

#7 One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio. This is actually one of those “rules of thumb” that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.) This ratio combines with...

Posted by: David Wright

» Cascade Day 8 - Principle #6 - Specialize – each member of a team assigned to a project should do what they do best for the length of that project.

(920 Views) (0 Comments)

This principle supports #5. With limited resources, there is another strong tendency to have IT staff ‘wear multiple hats’ on a project, especially the Business Analyst who is asked to also be the Project Manager and/or Lead Tester. Rather than getting more than you are paying for, you get less as an IT Staffer skilled in one role spends more time ...

Posted by: David Wright

» Cascade Day 7 - Principle #4 - Pick the right project(s) for the business

(740 Views) (0 Comments)

Principle #4 - Pick the right project(s) for the business. At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out? No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pic...

Posted by: David Wright

» Cascade - Day 6 - Principle #3: Use Architecture to describe the business, before and after projects.

(831 Views) (0 Comments)

Principle #3: Use Architecture to describe the business, before and after projects. “Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Architecture”, “Enterprise Architecture”, and ...

Posted by: David Wright

» Cascade - Day 5 - Principle #2: Projects change the business, so know the overall business first

(799 Views) (0 Comments)

Principle #2: Projects change the business, so know the overall business first A never-ending discussion in IT circles is about how much IT staff need to know about the business that the information systems are supporting. It is high-lighted by every want-ad for an IT job that says previous experience in the employer’s industry is mandatory. Is d...

Posted by: David Wright

» Cascade - Day 4 - Principle # 1: There is always more work to be done than people to do it.

(666 Views) (0 Comments)

Let’s look briefly at what each principle means or implies; which will serve as introductions to subsequent posts that will cover the principles in more detail. #1. There is always more work to be done than people to do it. Bordering on glibness, this principle summarizes the reality of virtually all organizations and activities, not just Informa...

Posted by: David Wright

» Cascade - Day 3 - Principles

(723 Views) (0 Comments)

Like you, I have read my fair share of IT books and blogs, and each author has to decide how to best present what they are trying to communicate. One way is to describe the problems/opportunities of interest to the reader, then document the new approach or method that solves the problems, etc.; the reverse is to document the new approach/method fir...

Posted by: David Wright

» Cacscade - Day 2 - what can you do to be successful?

(753 Views) (0 Comments)

The premise of these blog entries is that the situation described in the previous post can change, but it is usually slow-going; or worse, there can be an immediate channge when your department is outsourced; it happens. In the meantime, what can be done to be “successful” in your average IT department in your average company? What has to be do...

Posted by: David Wright

Previous Page | Next Page

Join the Premier Community for
Business Analysts, Business Process Professionals,
Systems Analysts, Data Analysts, and more…

The Community Blog for Business Analysts

Entries for the 'Systems Analysis' Category

Join the Premier Community for Business Analysts, Business Process Professionals, Systems Analysts, Data Analysts, and more…

The Community Blog for Business Analysts

Entries for the 'Systems Analysis' Category

Join the Premier Community for
Business Analysts, Business Process Professionals,
Systems Analysts, Data Analysts, and more…