Latest nexus articles

Most Useful Requirements Processes

scott.sehlhorst — Sun, 12 Aug 2007 00:11:05 -0500

High level overview of the processes that make up the bulk of requirements management work.

How Do We Speed up Software Testing?

scott.sehlhorst — Sun, 12 Aug 2007 00:09:56 -0500

By writing better requirements

Are your users stuck in "P" mode?

scott.sehlhorst — Sun, 12 Aug 2007 00:09:20 -0500

Provides comparison and understanding of looking at products in terms of what the products can do, versus what the user can do with the products.

The Happiness of Priorities

scott.sehlhorst — Sat, 04 Aug 2007 22:13:05 -0500

Managing prioritization with a whiteboard, and the Happy Brian List.

Have We Finished Yet

scott.sehlhorst — Wed, 01 Aug 2007 14:47:22 -0500

Article by Suzanne Robertson about how to approach writing requirements when you are under constraints that prevent you from completing them. Good article, very stimulating discussion in the comments.

UML 2 Activity Diagrams

scott.sehlhorst — Tue, 31 Jul 2007 21:54:49 -0500

From the article (by Scott Ambler):

UML 2 activity diagrams are typically used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule. Although UML activity diagrams could potentially model the internal logic of a complex operation it would be far better to simply rewrite the operation so that it is simple enough that you don’t require an activity diagram. In many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.

How Much Control Should Users Have?

scott.sehlhorst — Tue, 31 Jul 2007 00:09:58 -0500

Kathy Sierra discusses how to balance interface design between letting users do what they want, and making them do what you know they want - in the way you want them to.

Communicate the ROI for Design

scott.sehlhorst — Tue, 31 Jul 2007 00:08:52 -0500

Peter Merholz discusses sources of value to justify investment in design.

Requirements Documents - One Man's Trash

scott.sehlhorst — Sun, 29 Jul 2007 18:05:38 -0500

…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents - MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

Starting with Rolling Wave Planning

scott.sehlhorst — Sun, 29 Jul 2007 18:02:37 -0500

Project management for incremental delivery / iterative development projects by Johanna Rothman

A rolling wave plan is a continuous detailed schedule that's only a few weeks long. As you complete one week of detailed schedule, you add another week to the end of the schedule. With a four- week rolling wave schedule, I never have less than four weeks of detailed schedule, and I never have more than four weeks of detailed schedule.

Agile...Again

scott.sehlhorst — Sun, 29 Jul 2007 18:01:10 -0500

Discussion of agile vs traditional requirements management

Solve customer needs, not business ones

jefflash — Sat, 28 Jul 2007 12:45:48 -0500

If you want to be a bad product manager, create new products based on business desires and existing assets. If you want to be a good product manager, create new products that fill customer needs that are not currently being met.

Making product roadmapping work for your business

jefflash — Sat, 28 Jul 2007 12:42:08 -0500

Product roadmaps can be powerful assets to leading a technology business – buy only if they are created and managed in the context of appropriate policies. In fact, the product roadmapping process a company uses can be as important to its business as the roadmap itself. In the Product Strategy Network’s roundtable meetings on product roadmapping, field-tested practices and policies are presented in detail by PSN Members. Here are a few of the highlights:

Business Analysis: A potted history

craig.brown — Sat, 28 Jul 2007 08:20:09 -0500

This article is an informed and wide ranging history of the profession/role of the business analyst. Written by a developer for developers to help understand the role and how to work with them.

Agile Modeling Principles v2

scott.sehlhorst — Sat, 28 Jul 2007 01:31:53 -0500

Identifies and defines over a dozen principles of agile modeling. Good introduction or reminder

Yours, Mine And Ours

scott.sehlhorst — Sat, 28 Jul 2007 01:24:08 -0500

Presents philosophy that there are four classes of software:

MeWare: The developer creates software. The developer uses it. Nobody else does.
ThemWare: The developer creates software. Other people use it. The developer does not.
UsWare: The developer creates software. Other people use it. The developer uses it too.
NobodyWare: The developer creates software. Nobody uses it.

Includes detailed real-world analysis of City Desk, a software package - applying the ideas

Software Development's Evolution towards Product Design

scott.sehlhorst — Sat, 28 Jul 2007 01:14:42 -0500

Very insightful and fun view of how software is made - and how that process has evolved over time. Great images, great way to explain to "other folks" how software gets created.

Requirements Traceability

craig.brown — Tue, 17 Jul 2007 09:42:17 -0500

An introductory article about making sure you vesion control and maintain traceability over your requirements.

Requirements traceability is an important asect of good requirements management. If you are new to requirements management or business analysis this is a good introduction to some good practices.

Knowledge strategy - three journeys

craig.brown — Tue, 17 Jul 2007 09:11:23 -0500

The article is written in the context of implementing knowledge management strategies and it talks about a quality approach to project execution and requirements management.

This includes the importance of reconciling the details with the strategic direction when documentaing and managing corporate knowledge.

This is a useful article for anyone getting involved in the development of Knowledge Management systems or Business Process systems and Repositories.

The V-model; A testing and validation model

craig.brown — Tue, 17 Jul 2007 09:05:52 -0500

This link is to a series of blog posts on the V-model. The V-model is a testing and validation framework for software development projects.

This article is useful for business analysts new to the software development world and highlights key quality gates in the development and implementation of software. The articles focus on what a Business Analyst or Project Manager should know about the process.

The individual posts listed are

Introduction

The value of testing

The V-Model and the development process

Verifying on the way into the development cycle

Testing and verifying on the way out of the development cycle

Extending the V-Model