Recent Posts

Visualisation: Part 4

Wednesday 26th March 2014

Viewpoints matter

How does the world look to you?

 

This is often one of the areas where Engineers and Customers can get out of step. And in particular, is a big issue for Software Development and IT systems. Check out the image below.

 

Round or Square Columns

Round or Square Columns

Technical professionals such as Engineers and Software Developers tend to be detail driven and so probably look at the system from the ground up. So we would see round columns.

 

Entrepreneurs and Business Owners tend to see the world from the top down and so would see square columns. And this difference in perspective can be a problem in implementing a solution that works for the customer.

 

So here we have an image that represents the potential difference between the Engineer Viewpoint and Customer Viewpoint.

 

Requirements Management

The real issue here is Requirements Management. This is one aspect of Software Development where I like the V Model for Software Development and the European Space Agency Software Engineering process. It splits the problem down into steps and also lets you know whose language the documents at the step are written in. So User Requirements are written in the language of the user. Technical Requirements are written in the language of the technical professionals. And Requirements Analysis is required to determine the relationship between the different viewpoints. For most projects the analysis is used to translate User Requirements to Technical Requirements. So now we can all have a viewpoint that we understand and it is linked.

 

The V Model for Software Development

V Model

The general steps are:

 

  • User Requirements – in the language of the user
  • Product Requirements – in the language of the user and relevant standards and market needs
  • Technical Requirements – derived from both the above and in the language of the technician
  • Functional Decomposition – breaking the problem down into specific functions to be performed
  • Architectural Decomposition and Requirements Allocation – working out that is done in hardware, software, locally, remotely …
  • Detailed Design and Module Specifications – specific modules to be designed and tested

 

So we move from user language to technical language in a structured way that allows us to understand was is required and make sure nothing has been missed.

 

User Requirements and Technical Requirements

Requirements Analysis

Product Development Process

The Product Development Process is intended to ensure that the product meets its requirements and is delivered on time and on budget. And regardless of the size of the project the above steps are required. Who does them and how they are done is less important than that they are done. Smaller projects might not require a formal approach but any significant project certainly does. And this also helps to overcome the difference in viewpoint between Technical Professionals and their Customers.

 

The image for today’s blog post was provided courtesy of Dr Marc Dussault, The Exponential Growth Strategist who is always on the look out for examples of antimimeticisomorphism, which I am sure you’ll agree this is!

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2014 Successful Endeavours Pty Ltd

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.