jump to navigation

What is UML? What is Unified Modeling Language? July 17, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , , , , , , , , , , ,
add a comment
A collage of UML diagrams including use case d...

A collage of UML diagrams including use case diagram, class diagram, activity diagrams, sequence diagrams, deployment diagram,component diagrams, composite structure diagram, package diagrams. (Photo credit: Wikipedia)

 

What is UML?

UML is an acronym for Unified Modeling Language. UML is widely accepted as the de facto standard description language for the specification and design of object-oriented software systems. UML is a family of “languages”, or diagram types, that attempt to bring together the “best in breed” software specification techniques for describing software systems. Users and practicioners of UML can choose which members of the family are the most suitable for their application domain.

Personally, I have become associated with UML through my years and years of specifying software products. Several of the UML diagram types that I will discuss below are among my primary tools for communicating application and system requirements and software designs to programmers.

I do not advocate, nor do I personally practice, an over-attachment to UML. Like many of these project management and requirements management techniques, there is a time and a place for the proper introduction of these types of UML artifacts into the software development process. Programmers may be unfamiliar with the UML diagram types and symbology, and so if you are a business analyst, project, program or product manager, and you are using these types of project deliverables with a new staff of engineers, be prepared to explain the UML diagram type you are using, keep the introductions down to one or two different new UML “Languages”, or diagram types, at a time.

I also recommend that if you insert UML diagrams into your functional specification documents, and I recommend that if you have invested the time to properly prepare UML diagrams that you do leverage them into your spec docs, make sure that you include an explanatory prose component into your accompanying functional specification document’s text.

There are nine different types of UML languages, or diagram types:

1. Use Case.

2. Sequence.

3. Collaboration.

4. Statechart.

5. Activity.

6. Class.

7. Object.

8. Component.

9. Deployment.

Five of these diagram types render behavioral views, the use case, sequence, collaboration, statechart and activity diagrams, while the remaining four diagram types are concerned with architectural or static aspects of the software design.

 

How does UML help in specifying a software design?

UML is a graphical language that is based on the premise that any software system can be described in terms of interacting business entities and that various aspects of these entities and their interactions, can be described visually using one or more of the above nine types of UML diagrams.

Use Case diagrams represent and document the dialog between external (to the system under discussion, as in an embedded system) actors and the system.

Sequence and collaboration diagrams describe interactions between objects.

Activity diagrams illustrate the flow of control between objects.

Statecharts represent the internal dynamics of active objects.

 

What is UML 2.0?

UML 2.0 is a revision to Unified Modeling Language that incorporates several improvements to UML. UML 2.0 is only just now beginning to supplant UML as the de facto standard.

A shorthand description of UML 2.0 is that it is designed for more rigor of specification, and it can sometimes be too much, or too much of a fine-grained distinction to bandy about when in an actual day-to-day, working software development environment. You are very likely to be working with only a subset of the UML languages, or diagram types, I outlined above at any one given point in the development project.

UML 2.0, when the diagrams are laid out in a software program such as VisualUML or others, can actually be used to generate working object code. If the business analysts have developed their proficiency enough with UML diagramming software, they can actually construct and output from these programs working java (or other programming language) object code.

In order to obtain this level of integration with application programmers, UML 2.0 had to have more access to a more robust and constrained specification language. The improvements to UML 2.0 include:

1. New base classes that provide the foundation for UML modeling constructs.

2. Object constraint language, a formal method that canbe used to better describe object interactions.

3. An improved diagram meta-model that allows users to model systems from four viewpoints:

a. Static models (e.g., class diagrams)

b. Interaction (e.g., using sequence diagrams)

c. Activity (i.e., to describe the flow of activities within a system)

d. State (i.e., to create FSMs, or Finite State Machines, using state charts)

UML has always been used to not only specify software systems for systems and application programming, but also specification for embedded systems as well. This emphasis on the notion of time and state is evident in the way that sequence diagrams are implemented in UML, and indicates the special considerations that were undertaken to support embedded systems design in the original conception of UML.


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

What is pattern-based software development? What is pattern-based design for software projects? July 17, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , , , , ,
1 comment so far

UML class diagram describing the Prototype des...

Image via Wikipedia




What is pattern-based software development?

What was the original impetus behind the development of software development patterns, and why do we need them? Why did programmers invent patterns for software development?

Well, developing software is very difficult, and developing software that can be easily reused is even harder. the designs for sections of software code should be general enough solutions to be able to address future problems and requirements flexibly while still being specific enough in order to address the current problem at hand. Programmers that are experienced at designing software systems know better than to design their system using one-off problem solutions, and instead reuse patterns that they have grown familiar with through prior use in similar situations and scenarios and reuse these solutions as a basis for their new designs. The basic fundamental principle of software engineering known as the “Principle of generality” predicts and encourages this behavior.


What’s so great about programmers using pattern-based development on software projects?

For one thing, it is absolutely fascinating to sit in a meeting room with a group of programmers who have been working all together on a software development project using patterns for a few months. The rate of information exchange is extremely high, with a idea mentioned by one programmer, and a few others simultaneously finishing the first programmer’s sentence with an exclaimed, unison word like “Bridge!”, and then one of them scribbling lines of code frantically on the whiteboard as the rest nod in compliment.

The language of the programming team using patterns is mysterious and magical, almost like incantations spoken in some artful black language. Many computer science instructors contend with conviction that the teaching of patterns and the learning of them speeds the learner’s adoption of the principles of object oriented software technology. It is undeniable that the learning of patterns improves the programmers’ development vocabulary.

Software design patterns also help in finding appropriate objects, in determining the apropos object granularity and in designing a software system that is architected from the outset to better adapt to change. At the design level, patterns enable large-scale reuse of software architectures by capturing the expert knowledge of pattern based development and distributing it throughout the development team.

It is generally acknowledged that these are the two most important benefits: the way in which they form a vocabulary for articulating design decisions during the normal course of development conversations among promgrammers. This can also come into play during the close programming work of so-called “pair programming“, among those who have found it to be useful for them.

When you are working with a group of programmers who are either working in pairs or as part of a group using pattern-based development, you frequently hear talk like “I think we need a strategy here”, or, from one programmer to the rest of the group, “Let’s implement this functionality as an Observer”.

Programmers’ familiarity with pattern-based development has also become a kind of hiring shorthand. Whenever a talented programmer leaves a software development team I am leading, and we need to replace him or her with anther programmer, I use the “Do we need a programmer familiar with design patterns” question as a line of demarcation for recruiting and hiring decisions. The answer is *not* always to hire an expensive programmer intimately familiar with design patterns, either.

It is fashionable in development manager circles to use design patterns as a hiring demarcation line as well, as in the following exchange:

“So…regarding design patterns: what would you say is your favorite design pattern?”

“Well, the factory, I guess.”

“Yeah…OK…thanks for coming down.”


What does a software development pattern look like?

A pattern is a problem-solution pair that can be applied in a similar fashion in new contexts; the pattern is complete with advice on how to apply it in the new context. It is important to note that the formal definition of a pattern is not consistent in the literature.

There are three types of patterns:

1. An architectural pattern occurs across software subsystems.

2. A design pattern occurs within a subsystem but is independent of the language.

3. An idiom is a low-level pattern that is programming language-specific.

Each individual pattern is compromised of four elements:

1. A name. Some of the names of the software design patterns can be rather whimsical: “flyweight”, and “singleton”. The whimsy is to serve the purpose of making the patterns memorable to programmers.

2. A problem description. The problem part of the pattern describes the problem and its context, as well as specific design issues such as how to represent algorithms as objects. The problem statement may also speak about when it is best to apply this particular pattern and may also describe class structures that are symptoms of an inflexible software design.

3. A solution to the problem. The solution part of the design pattern does not desibe any one particular concrete design or implementation, but only describes the elements that make up the design, The solution only provides a general arrangement of objects and classes which can be used to solve this type of problem.

4. The consequences of the solution. This part of the design pattern describes the results and inherent risks and trade-offs associated with applying this particular design pattern. It may include the impact of this design pattern on space and time, programming language and implementation issues, or include notes on software flexibility, system extensibility, and portability. These consequences are critical for evaluating alternative software design patterns.


What is the history of software design patterns?

The concept of design patterns was first introduced by Christopher Alexander for use in architecture and town planning. He realized that architects encounterd the same sorts of problems when engaged in the design of buildings and once an elegant architectural solution to these common problems was discovered, it could be repeated over and over again. In 1977, he wrote a book, published by the Oxford University Press, called “A Pattern Language”, in which he stated:


“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”

Design patterns as an idea were first applied to computer software programming in the 1980’s, when the infamous “Gang of Four” book, “Design Patterns: Elements of Reusable Object-Oriented Software” popularized the use of design patterns. Ward Cunningham, Kent Beck, and Jim Coplien were some of the initial practicioners and popularizers of software design patterns.


What are the “Gang of Four” software design patterns?

The “Gang of four” book first introduced this set of patterns into the software programming world. The book lays out 23 design patterns for software development, and it was first published in 1995. Building upon the work of Kent Beck, Christopher Alexander, and others, the gang of four set out to redirect all of the effort being put into “rengineering the wheel” in software development teams all over the world and redirect it into something much more useful.

The book was an instant hit with computer programmers, selling over half a million copies since its publication in 1995 and undoubtedly influencing the thoughts and code of millions of computer programmers worldwide. Many computer programmers can vividly remember buying their first copy of the book and in addition many computer programmers look upon their reading of the book as a rite of passage. It can be a difficult book to get through, and it is not infrewunt for even advanced computer programmers to have to spend several readthroughs in order to extract the desired effects out of their investment of time in the gang of four’s words. The book did two very important things for programmers:

First, computer software programmers were introduced to the world of design patterns, where each pattern is a prepackaged solution to a common design problem. The book encourages programmers to look at their code and to find and identify common solutions to common problems. Programmers should give each solution a name, and they should talk about what each solution is good for, and when to use each solution, and when to reach for something that is a more appropriate solution. If all of these solutions are documented well, then over time more and more programmers will become better and more effiecient programmers, and this knowledge can be distributed throughout the developer community in the most direct and sane way.

Secondly, the book describes 23 software design patterns that are organized into three groups based on the intention for their use: creational, behavioral, or structural:

1. Creation design patterns are associated with object creation and their intent is to allow programmers to create software objects without actually knowing what they are creating beyond the interfaces themselves. There is a fundamental principle in computer programming, known as information hiding. When programmers code using interfaces to object creation and objects, then they are following this fundamental principle well.

As described by Gamma, Helm, Johnson and Vlissides, the “Gang of four”, these creational patterns include the abstract factory, the builder, the factory method, the prototype, and the singleton.

2. Structural design patterns are concerned with organization classes. Structural design patterns are static in nature; they are not designed to change. As laid out by the Gang of four, structural design patterns include the adapter, the bridge, composite, decorator, facade, flyweight, and proxy.

3. Behavioral design patterns are concerned with runtime or dynamic system behavior of the program, and they help define the roles of software objects and their interactions. By their dynamic nature, behavioral patterns are designed to change, and are not static and contain very little “structural” code. The gang of four describe behavioral software design patterns called the chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template method and visitor.

In the years that have followed the publication of the gang of four book, and as I will get into in more depth here in a moment, many different sets of alternative design patterns have been proposed. the original gang of four patterns – the 23 patterns I wrote of above – really stick to the old school, middle ground of object-oriented software design. Smaller than a database system, but larger than just a simple hashtable. They focus on some very key questions that face all programmers that are tasked with building an object oriented software system: how do you know what types of objets to create, how many, and how? How should these objects relate and interoperate? What should they know about each other? How should they be coupled together? How can programmers swap out parts that are likely to change frequently with the most efficiency?


What are some of the situations in which a software design pattern might be used?

Each individual situation which is faced by software programmers will have an individual solution tailored for that specific situation. If this were not the case, then a piece of complete, reusable software code could be used, instead of the rough problem-solution description of a design pattern.

It is not difficult, however, for me to illustrate a few of the scenarios and what type of design pattern could potentially be used to address this situation:

If a programmer is faced with a situation in which there needs to be one and only one instance of a class in the application – the single class that everybody uses. This would be a scenario for the singleton pattern.

If a programmer needs to include code from another programming language to best solves the problem at hand, then the programmer could use the Interpreter design pattern in order to use that code programmed in another language directly.

If a programmer is faced with a scenario in which an object needs to be created according to a complex, precise, and changing, set of parameters. In this circumstance, perhaps the builder pattern would be best to utilize.

If a programmer or development team is faced with a scenario where they have objects which need to take on additional responsibilities at runtime in addition to their established responsibilities, then the decorator design pattern made be called for.


Are there any other popular sets of software design patterns?

There are indeed many other sets of software design patterns. For instance, Martin Fowler laid out a very popular set of software analysis design patterns in his 1996 book, “Analysis Patterns: Reusable Object Models” , and there was also a set of software architecture and design patterns laid out in the excellent and well-read book, also published in 1996, “Pattern-Oriented Software Architecture, Volume 1: A System of Patterns“.

But one of the most popular and well-known, regarded, and most-used set of software design patterns was popularized by Craig Larman in his 2002 book, “Applying UML and Patterns“. He called them the GRASP patterns, for general principles in assigning responsibilities, and they are a fairly high-level set of patterns for software design. There are nine GRASP patterns for software design:

1. Creator.

2. Controller.

3. Expert.

4. Low coupling.

5. High cohesion.

6. Polymorphism.

7. Pure fabrication.

8. Indirected.

9. Protected variations.

I will select one of the GRASP patterns I have listed above and describe what the pattern actually is in terms of the name of the design pattern, the problem the design pattern is trying to solve, and the solution for the problem as implemented using the design pattern.

For instance, a scenario that would be best served by the Creator design pattern would be one in which the problem is that it is unclear who should be responsible for creating a new instance of a class.

The solution as proposed by the Creator pattern would be to assign this responsibility to a class B to create an instance of class A if one or more of the following is true: (a) B aggregates A objects, (b) B contains A objects, (c) B records instances of A objects, (d) B closely uses A objects. B has the initializing data that will be passed to A when it is created.


How about design patterns in the Ruby programming language?

You probably realized that I wasn’t going to write an entire article of this length and depth without pimping Ruby. Design patterns are particularly easy to implement in Ruby, partially because of similarities between Smalltalk, the programming language used by the Gang of four to illustrate their programming examples in their design patterns book, and Ruby, and partly because of syntax peculiarities inherent in the Ruby programming language.

Ruby’s absence of static typing lowers the overall number of lines of code to begin with, and the Ruby standard library (if you have been paying attention, you recall the difference between code libraries and design patterns) makes it possible to implement many of the most common design patterns in Ruby with a single one-line include.

Other design patterns are essentially built into the Ruby programming language itself. For instance, a Command object in the canonical Gang of four sense is a state-aware code wrapper, something very closely approximated by a Ruby construct known as a Proc, or a Ruby code block object. This is not to say that although a simple Command construct can be implemented in Ruby with a single one-line include, if we add more complex state and behavior information to the block, the implementation will not need some additional Ruby code. As I stated earlier in this article, and without equivocation, design patterns do not lead to direct code reuse, this is the work of software libraries.

The main point I am trying to promote is that because design patterns are the common idioms of object-oriented software code, a good or great programming language should make design patterns easy to implement, or even make the use of them nearly a transparent excercise, as if the design patterns’ usage was inherent in the use of the language itself.

Ruby works marvelously well in a pattern-based software development environment because:

1. Static typing reduces code bloat and overhead. Common patterns can be implemented in less code. You can turn a class into a singleton with a simple “include singleton” command.

2. Ruby has code closures, which means that chunks of code can be passed around complete with their associated scope within a program without having to construct entire classes and objects whose only purpose is this scope and code transferral.

3. Ruby classes are real objects, so any runtime operation that can be applied to a Ruby class can be used to implement the logical intent of any of the design patterns. A Ruby class can be modified by adding or deleting methods. A class can be cloned and the copy can be modified while leaving the original class unmodified.

4. Ruby has mixins, which in addition to the same inheritance of other programming languages, is a simple yet sophisticated way in which Ruby code can be shared among several Ruby classes.

One of the books I recommend all Ruby programmers read is “Design patterns in Ruby“, by Russ Olsen, with a foreword by renowned Ruby programmer Obie Fernandez.

In the book, you will learn why there are only 14 patterns in Ruby instead of 23 original Gang of four patterns, and you will also find out about three new Ruby-specific design patterns that have a great deal of usefulness in Ruby.


Are there any drawbacks or negatives to using pattern-based software development?

Well, actually, there are several drawbacks to all of this talk of pattern-based software development.

One of the main drawbacks, and one of the most important thing for technical project managers and business stakeholders as well as senior managers to keep in mind, is that patterns do not lead to direct software reuse.

Direct reuse of sections of software code is for software libraries. Patterns do not create or promote software libraries of reuable plug-and-play software code, but rather lead to reuable design, architectures and techniques which can be converted by computer programmers into unique program code.

Even though the cutesy names of software design patterns may lead you to believe that they are also simpe to learn, they are not. It is easy enough to master some of their names, and to also memorize their structure visually, but it is not very easy to see how they can lead to actual design solutions. This can take even very experienced computer programmers years and years of practice, education and working experience.

Integrating the use of software patterns into an actual, real-world development organization’s daily development life and regular deployment cycle can be a daunting task. The integration, aside from the demands the aforementioned education and training can take on a development staff compromised of computer programmers unfamiliar with the software design patterns described above, is a very labor-intensive activity.

A software development team’s programmers may experience pattern overload, whereby in their unending quest to use pattern-based techniques, they have become an obsession rather than as an effective and efficient means to an end. Aa mentioned above, software design patterns are no silver bullet, and do not lead to direct code reuse, but rather provide another approach to systematically solving software design problems that are commonly and frequently encountered by software development teams.


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

What are the qualities of bad software code? How can you tell if your software project has bad code? July 12, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , ,
1 comment so far
User:Dreftymac/Docs/ImageDisclaimer

Image via Wikipedia

What are the qualities of bad code? How can you tell if your software project has bad code?

Troubled software projects and bad code are facts of life in the software business. Today’s applications, system software, even embedded and operating systems programming is increasing being outsourced or at least distributed.

The need for being able to quickly evaluate the quality of software code, describe any known issue in simple aterms and then execute on a planned approach to rectify these issues is greater than ever.

A common vocabulary for project teams, refactoring engineers, and project managers and stakeholders is of a fundamental assistance in manageing software development projects.

You may find yourself sitting in a meeting or conference room or perhaps on a conference call with a group of computer programmers who are discussing some sections of code, or if you are particularly unlucky, perhaps an entire application of software development project, that is troubled using some of these below listed terms. After each of these negative, “bad code” terms I have tried to describe what is meant by each of these terms for bad software. After each description, I list the term for the opposite, positive “good code” quality contrary to the bad code quality.

1. Fragility: When changes in the software code cause the system to break in places that have no conceptual relationship to the part that was changed. This is a sign of poor design. The opposite of fragility is known as robustness.

2. Immobility: When the code is hard to resuse. The opposite of immobility is known as re-usability.

3. Needless complexity: When the design is more elaborate than it needs to be. This is sometimes also called “Gold plating”. The opposite of complexity is known as simplicity.

4. Needless repetition: This occurs when cut-and-paste of code segments is used too frequently. The opposite of repetition is known as parsimony.

5. Opacity: When the code is written in such as manner as it is not clear. The opposite of opacity is known as clarity.

6. Rigidity: When the design is hard to change because every time you change something, there are many other changes needed to other parts of the system. The opposite of rigidity is known as flexibility.

7. Viscosity: When it is easier to do the wrong thing, such as a quick and dirty fix, than the right thing. The opposite of viscosity is known as fluidity.

In order for your software development project to feature the opposite, more desirable positive qualities to the ones listed above, your project must exhibit a good software architecture, solid software design, and effective coding practices.

For further reading on this topic, I highly recommend the excellent book by R.C. Martin, “Agile Software Development, Principles, Patterns, and Practices“, Prentice-Hall, Englewood Cliffs, NJ, 2002.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

What is software traceability? What is a software requirements traceability matrix? July 12, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , , ,
add a comment

What is Traceability in software development?

In my experience working on custom software development projects, the number one cause of project failure is inadequate requirements. When programmers code either without requirements or with inadequate requirements, nothing good ever comes of it.

The relationship between the requirements, the source of those requirements, and the system design that is ostensibly being built to enable those requirements, is what code traceability is all about.

I think it is very important to point out that regardless of the software development lifecycle process model you and your team happen to be following, be it a traditional “Waterfall” type software model or a so-called “Agile” fixed-iteration development lifecycle, documentation and code traceability is paramount.

If your software has provided for a high level of traceability, then the requirements can flow down through the design and code and then can be traced back up at every stage of the process.

This makes it a simple matter to trace a coding decision back to a design decision to satisfy a corresponding requirement.

In embedding systems software engineering, traceability is vital because hardware constraints can act as limiting factors on design and coding decisions that may not be as easily associated with a requirement as in a non-embedded system design.

When even a basic “traceability matrix” is not provided for on a software project, then the lack of a traceability path from design and coding decisions back through to the requirements can lead to severe difficulties in extending and maintaining the system.

What is a software traceability matrix?

A software traceability matrix document can take many different forms, but one of the most common forms is a table-like document that serves simply as a graphical representation of all of the cross referenced links between project deliverables and artifacts, and the code.

This cross referenced table is constructed, usually using a spreadsheet application program, by listing the relevant software documents and then the doe unit as columns, and each software requirement as a row.

An example of a software requirement tracing matrix.

If you use a spreadsheet program, then you can create multiple matrices sorted and cross-refernced by each column as needed. For example, you could provide a traceability matrix sorted by test case number, which could serve as a very apropos appendix to the test plan.

The traceability matrices should be updated at each step in the software life cycle. For example, the column for the code unit names, things like procedure names, object classes, etc., can not be added until after the code is developed.

What are the elements of a good traceability matrix?

A traceability matrix is a document, sometimes in the form of a table, that will provide a cross reference between all the documentation and software code in a system.

At a very minimum, a good traceability matrix will provide links, or cross references showing the associations between the following elements:

1. From the requirements to the stakeholders who first proposed these requirements, with the dates they were first proposed.

2. The associations between any dependent requirements listed.

3. From the requirements through to the system design, or functional specification document.

4. From the design to the relevant code segments. (oftentimes referencing the technical specification document).

5. From the requirements to the test plan document.

6. From the test plan to the relevant test cases.

What is requirements traceability?

Software requirements traceability is the ability for a project team to provide references that document the relationships between the software requirements, their sources, and the system design. If software requirements traceability has been provided well, then the requirements can be linked to their source, to other requirements, and to design elements.

Requirements traceability links between the different requirements, source traceability links these requirements to the stakeholders who proposed those requirements, and design traceability link from the requirements to the system design documents.

The software requirements document, sometimes referred to as the SRS, or software requirements specification document, MUST be “traceable”, because the software requirements provide the starting point for the entire traceability chain.

It is very common within professional project management organizations, or PMOs, to enact and enforce traceability policies which codify how much information regarding requirement relationships is required to be maintain, and the format in which this information is to be presented. There are a number of open source and proprietary open-source tools which can be used to help improve a software organization’s requirements traceability.

A traceability matrix sorted by requirement numbers that correspond to a numbering scheme

The overarching goal of software traceability and software traceability matrix is to ensure that for critical software, nothing falls through the cracks. Ultimately there is a way of mapping for each requirement which test cases exist to cover that requirement and the functional specification.

As shown in the sample traceability matrix above, one way to show the traceability from requirements through design and testing is through the use of an appropriate numbering system throughout the documentation for the system. For example, a requirement numbered 3.2.2.1 would be linked to a design element with a similar number (the numbers don’t have to be the same so long as the annotation in the document provides traceability). The main intent here is to show that all the appropriate documents and project deliverables are connected through referencing and notation.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

What is a User Story? How are they used in Requirements Gathering and in writing User Acceptance Tests? October 3, 2010

Posted by HubTechInsider in Agile Software Development, Definitions, Project Management.
Tags: , , , , , , , , , , , , , , , , ,
add a comment
user stories image

Image via Wikimedia

What is a User Story? How are they used in Requirements Gathering and in writing User Acceptance Tests?

User Stories are short conversational texts that are used for initial requirements discovery and project planning. User stories are widely used in conjunction with agile software development project management methodologies for Release Planning and definition of User Acceptance Criteria for software development projects.

User Goals, stated in the form of User Stories, are more closely aligned with Business Priorities than software development Tasks and so it is the User Story format which prevails in written statements of User Acceptance Criteria.

An Agile Project Team is typically oriented to completing and delivering User-valued Features rather than on completing isolated development Tasks.These development Tasks eventually combine into a User-valued Feature).

User Goals are not the same things as software development Tasks. A User Goal is an end condition, whereas a development Task is an intermediate process needed to achieve this User Goal. To help illustrate this point, here are two example scenarios:

1. If my User Goal is to laze in my hammock reading the Sunday Boston Globe newspaper, I first have to mow the lawn. My Task is mowing; My Goal is resting. If I was able to recruit someone else to mow the lawn, I could achieve my Goal without having to do the mowing, the Task.

2. Tasks change as implementation technology or development approaches change, but Goals have the pleasant property of remaining stable on software development projects. For example, if I am a hypothetical User traveling from Boston to San Francisco, my User Goals for the trip might include Speed, Comfort and Safety. Heading for California on this proposed trip in 1850, I would have made the journey in a high technology Conestoga wagon for Speed and Comfort, and I would have brought along a Winchester rifle for Safety. However, making the same trip in 2010, with the same User Goals, I would now make the journey in a new Boeing 777 for updated Speed and Comfort and for Safety’s sake I would now leave the Winchester rifle at home.

· My User Goals remained unchanged, however the Tasks have changed so much that they are now seemingly in direct opposition. User Goals are steady, software development Tasks as stated on SOWs (Statements Of Work) are transient.

· Designing User Acceptance Criteria around software development Tasks rarely suits, but User Acceptance Criteria based on User Goals always does.

A User Story is a brief description of functionality as viewed by a User or Customer of the System. User Stories are free-form, and there is no mandatory syntax. However, it can be useful to think of a User Story as generally fitting this form:

“As a <type of User>, I want <Capability> so that <Business Value>”.

Using this template as an example, we might have a User Story like this one:

“As a Store Manager, I want to search for a Service Ticket by Store so that I can find the right Service Ticket quickly”.

User stories form the basis of User Acceptance Testing. Acceptance tests can be created to verify that the User Story has been correctly implemented.

User Story Card

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies,software developmentAgile project managementmanaging software teams, designing web-based business applications, running successful software development projectsecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurshipecommercetelecommunications andsoftware development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

%d bloggers like this: