Conway's Law

...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

Read more about Conway's Law on Wikipedia. Also briefly discussed by Michael Nygard in Chapter 4 of Beautiful Architecture.

Technical Debt

Technical Debt is an interesting and familiar metaphor within software development.

To extend if further we can even consider scenarios whereby we choose not to take out a loan when designing, however it is still prudent to make regular payments into the bank account otherwise you begin to creep into the overdraft. Design decisions taken up-front may have been made with a full-understanding of the requirements and even some built-in flexibility because we had the cash available to avoid taking out a loan. However the business changes and new features are introduced which conflict with the conceptual integrity of the original design. Without regular payments into the bank account in the form of refactoring we eventually end up with unmanageable debt whereby the only solution is to bring in the administrators. The administrators salvage what they can but the reality is we need to start re-building from the ground-up.

The essence of this metaphor is that refactoring is essential to the longevity of software. This acts as a prompt for us to promote the practice of refactoring, however the success of refactoring is reliant upon either maintaining or reliably evolving the conceptual integrity of the design. This presents a challenge for small to medium size development teams whereby the turnover rate of architects or senior developers is high.

Scott Wood’s Technical Inflation metaphor featured on Martin Fowler's Bliki similarly applies but in the context of technological debt as opposed to design debt.

Resources: Technical Debt on Wikipedia

BPMN 1.1 Notation

A useful poster/PDF for the office is available here.

See the Business Process Technology Group wiki for more BPMN info.

Use Case Points

An approach to estimating and planning with use cases:

• Complicated use cases generally take longer to code than simple use cases
• By assigning points to use cases we can use this to measure the size of the application and derive an expected duration for the project using the team's rate of progress
• Points are assigned by weighing the complexity of the use cases and actors and then adjusting their combined weight to reflect the influence of the nonfunctional and environmental factors
  

The number of use case points in a project is a function of the following:

• the number and complexity of the use cases in the system
• the number and complexity of the actors on the system
• various non-functional requirements (such as portability, performance, maintainability) that are not written as use cases
• the environment in which the project will be developed (such as the language, the team’s motivation, and so on)

See: Estimating with Use Case Points

Bar graphs vs. Pie charts

Worth reading the next time you are deciding upon which kind of graph to create to make the right suggestions with your statistics:

Seth's Blog: Bar graphs vs. Pie charts

Quality Software Requirements

A few pointers to evaluate requirements:

• Correct - a true statement of something the system must do
• Complete - describes all significant requirements of concern to the user
• Consistent - does not conflict other requirements
• Unambiguous - subject to one and only one interpretation
• Verifiable - can be tested cost effectively
• Ranked for Importance & Stability - can be sorted based on customer importance and stability of the requirement itself
• Modifiable - changes do not affect the structure and style of the set
• Traceable - the origin of each requirement can be found
• Understandable - comprehended by users and developers

Signs of bad requirements:

• Undefined jargon is used
• The word 'use' is used
• Conjunctions can be found e.g. and, or, also, with
• Exception statements are used e.g. if, but, when, except, unless
• Graphical depictions are used in lieu of a detailed textual description
• Generalisations are used e.g. generally, usaully, approximately
• Relative terms are used e.g. user-friendly, fast, flexible, intuitive
• Suggestive terms are used e.g. could, should, may, might, probably
• Clarifications are used e.g. that is, for example, like
• The word 'not' is used e.g. not exhaustively saying what 'is' allowed

Managing Software Requirements: A Use Case Approach

Initial Requirements Modeling

Early in a project a developer invariably has to answer difficult questions:

• "What are you going to build?"
• "How much do you think it's going to cost?"
• "What benefits will be gained?"
• "How long do you think it's going to take?"

To answer these questions initial requirements modelling is required:

• High-level Usage Modeling - use cases where important ones described with a few bullet points and others just named
• Domain Modeling - major business entity types (without attributes) and their relationships
• User Interface (UI) Prototyping - paper sketches of critical screens/pages

The end product of the initial modeling efforts can be summarised in an initial project vision consisting of a few paragraphs. This concept has been promoted by the Rational Unified Process (RUP) and the Project Management Institute (PMI). In addition a couple of scope diagrams (UML or BPMN) which describe the business are useful to present to key project stakeholders.

How Much Initial Requirements Modeling Should You Do?
Agile Model Driven Development (AMDD)

Business Process Modeling Notation (BPMN)

A standard notation for drawing business processes in a workflow, now maintained by the Object Management Group (OMG). BPMN aims to provide a notation understandable by all business stakeholders bridging the communication gap between business analysts and technical developers. The four basic categories of BPMN elements are:

Flow Objects:

• Events - a trigger or result represented by a circle, can be Start, Intermediate or End
• Activities - a task or sub-process represented by a rounded-corner rectangle
• Gateways - decisions or forking/merging of paths represented by a diamond shape

Connecting Objects:

• Sequence Flow - the order which Activites will take place represented by a solid line arrow
  Message Flow - messages between to participants represented by a dashed line with an open arrowhead
• Association - used to associate flow objects represented by a dotted line

Swimlanes:

• Pool - organises different activities into categories using a big rectangle
• Lane - organises activities more precisely as a sub-part of the pool

Artifacts

• Data Objects - shows what data is required or produced in an activity represented by a page with folded corner
• Group - used to group different activities with a rounded-corner rectangle and dashed lines
• Annotation - used to give the reader more understanding

Business Modeling & Integration Domain Task Force (BMI DTF)

Software Requirements

“A requirement is anything that drives design choices.”

http://www.processimpact.com/