Software development goes through a process which is known as software development process. In simple term we define the process as follows
- The process takes a problem of the proposed system
- Create a solution for the problem of the software
A process is generally iterative. Each iteration builds upon
- Taking a set of requirements based on the identified problems
- Creating conceptual design mock-ups based on those requirements
- Creating technical design diagrams based on those requirements and conceptual designs
- Developing working software based on requirements, conceptual design mock-ups and technical design diagrams
- Testing the working software that being developed
- Implement the software if certain tests are passes
This process is repeated for each set of requirements, until creating a complete solution for the project.
Many developers are eager to go straight into coding despite not fully understanding what to program in the first place. Evidence suggests that diving straight into implementation work is a leading cause of project failure. In a survey from The Standish Group, the most common causes of project failures are related to issues in requirements and design.
Requirements are the demands of client that must be implemented in a product. They are starting point of a software project- one must have to understand what his/her client wants.
In order to gather details requirement we need to ask more than the simple client vision. To gather detail requirements we need to
- Actively probing the client vision
- Clarifying what may not have been told (missed) by the client
- Asking questions about the issues that client may not have even considered
These will allow us to understand the full scope of
- What our client wants in a product and
- What we need to build.
So we need to do this before start coding.
Besides identifying specific needs, we need to ask about potential trade-offs (a compromise / sacrifice- in this case it means the client exactly don’t want any feature) the client will need to make in the solution.
A client may decide to sacrifice a feature in order to ensure that a program runs faster, if speed is an important need.
Once requirements and trade-offs are identified, they may serve as the foundation for design.
Example of eliciting requirements
For better understand how to elicit details requirements, think like an architect i.e. think about the structure and behavior of the proposed software.
Consider the following scenario. You’re hired to design a house. Before you start laying the foundation, you must first understand what the homeowner wants. This starting point is known as eliciting requirements.
Say the homeowner wants a wants a single story house. It needs to have a gym, a bathroom, three bedrooms and a living room.
Eliciting requirements involves not only listening to what the client is telling you, but asking questions to clarify what the client has not told you.
For instance, here the client didn’t tell you about having a kitchen. So you can ask the homeowner some follow up questions as follows-
- Do you anticipate needing a kitchen?
- Should the rooms all be same size? If not, which should be bigger or smaller?
- How big should the house be overall?
- Are there external design constraints? For example, building restrictions put in place by the community?
- Should the house face a particular direction to take advantage of passive solar energy or scenic views?
- Which rooms should be furthest apart?
- Which rooms should be close together?
The art of eliciting requirements is found in asking revealing follow up questions. Once these questions are answered, you now have an initial set of requirements allowing you to start thinking of possible designs of a building.
Similarly when you understand everything of client’s requirements then you will be understand what to develop for the client.
After gathering the initial requirement our next step of the development process is produce
- A conceptual design and
- A technical design
So we need to create two different kinds of artifacts whose are-
- Conceptual mock-ups and
- Technical diagrams
Conceptual designs are created based on initial requirements. At this point we will focus on the software system by identifying components, connections and responsibilities of the software system. It outlines the high level concepts of our final software product. More specific technical details deferred until we work with technical design.
Conceptual designs are expressed or communicated through conceptual mock-ups. These are visual notations that provide initial thoughts for how requirements will be satisfied. Software UI mock-ups are often presented as wireframes. Wireframes are a kind of blueprint or basic visual representation of the product. See the example below of a wireframe mock-up for a web page.
Whether for user interfaces or for the software product itself, conceptual mock-ups can be
- Hand drawn sketches or
- Drawings made using computer tools.
Conceptual mock-ups help us to clarify design decisions with clients and users by providing a simple way to illustrate and discuss how a product will work.
Mock-ups illustrate major components and connections/ relations between the components. Once you start to create a mock-up, you may more easily see what components are missing or may not work. In that case require further clarification with your client or involve additional conceptual design work. Every component also has a task it needs to perform. This is known as its responsibility. Mock-ups do not outline technical details, because that falls outside the scope of conceptual design.
Let us return to the metaphor of building a house. You focus on the house design by identifying major components and connections and defer the technical details.
For example, the components from your house project are, the lot on which the house will be situated-
- The house itself,
- The kitchen,
- The gym,
- The bathroom,
- The bedrooms and
- The living room.
Connections in the house can relate the components. For example if the living room is openly accessible from the kitchen, the living room has a connection to the kitchen.
Each component has a task it needs to perform, known as responsibility. For instance-
The gym’s responsibility is to provide the homeowner with space and power for fitness activities and equipment.
Similarly, the kitchen’s main responsibility is to provide space for storing kitchenware, appliances, food supplies, and power and water for meal preparation.
As a main component, the house has the overall responsibility of providing enough power, water, and support for all the required components within it.
Note we don’t mention specifics about wiring and plumbing. These are technical details that cannot be fully addressed until the conceptual mockups are completely understood. For instance, determining the size of the electrical distribution panel for the house will require adding up the power requirements necessary to energize each of the rooms.
So it is recommended to finishing the conceptual design before moving on to forming the technical design. It is the best practice- because- The clearer your conceptual design is, the better your technical designs will be. So we will be able to build the right software.
.Technical designs are builds based on conceptual designs and requirements. Technical designs are usually design to define the technical details of the solutions.
In conceptual design we actually
- Identify the major components of the system
- Connection between the identified components and
- The responsibilities of those components as the part of the whole software system.
The technical design brings these information to the next stage.
The main goal of technical design describes how these responsibilities are met. The technical design is not finished until each component has been refined to be specific enough to meet the design detail.
In order to accomplish technical design we will break down the components into smaller and smaller components. At this point i.e. during breaking a component further, we need to keep in mind that “each smaller component will have to be specific enough for design in detail.” By breaking down components further smaller components; we get a level where we can do a detailed design of a particular component. The final result is- each component will have their technical details.
In order to communicate technical design we need to use technical diagrams. Technical diagrams visualize how to address specific issues for each component. There are many technical diagrams that can be used to describe the structure and behavior of components. Technical diagrams help us to coordinate development work.
The gym component will require further components like a floor. The floor will be responsible for supporting a lot of weight. Are homeowner is training to be an Olympic lifter. By breaking down components more and more into further components (each component with specific responsibilities) you get down to a level where you can do a detailed design of a particular component, such as, describing how to reinforce the floor.
Compromise in Requirements and Design
In the design phase, there may need to be compromises in creating an acceptable solution. Constant communication and feedback is key to creating the right solution that meets client needs and works within any restrictions that may exist.
What if reinforcing the floor of the gym requires putting in columns or beams in the basement below the gym? What if the homeowner also wanted a wide open space in the basement with good head room? Sometimes conflicts like this can happen.
You and the homeowner will need to work out a compromise in the solution. Constant communication and feedback is key, so that the solution is acceptable.
If components and connections and their responsibilities in your conceptual design prove impossible to achieve in the technical design or fail to meet the requirements, you will need to go back to your conceptual design and rework it.
It is important to contentiously check with clients that “Conceptual mock-ups capture what they want.”
Continuously check your Conceptual mock-ups capture the user demand because redesign in planning stage is easier than coding stage. So seat with client again and again and check and confirm that your Conceptual mock-ups meet their requirements properly.
Larger systems require more design time because they have more components, connections and responsibilities. Also these components are large enough. So need to refine down them into smaller components before move to technical design.
Once a feasible design has been agreed upon, the technical diagrams become the basis for constructing the intended solution. Components at this stage may be refined enough to become collections of functions, classes, or other components. These pieces become a more manageable problem that developers can individually implement.
When we look at our requirement,
“As a learner, I want to search for relevant courses through a search page.”
From the requirements we recognize-Search page and Course as the components.
The search page has the responsibility of searching for relevant courses.
By sketching a mock-up of our user interface, we notice many missing components.
Example (Use of Conceptual and Technical Design in Software)
Let’s apply what we learned by the example of building architect into software design.
Suppose we have a design task for a university course search website with the following requirement-
“As a learner, I want to search for relevant courses through a search page.”
Now, let’s do a conceptual design.
In making a conceptual design of a building, we try to recognize appropriate components, connections and responsibilities and avoid technical details.
Conceptual design of software involves user interfaces.
In software conceptual mockups can be a hand drawn sketch or a drawing made using computer tools.
One might be wondering about
• How a search keyword is entered in the search page.
• How is the search started?
• How is the list of search results displayed?
These flaws in the initial mock-up require further clarification with your client, or more conceptual design work.
Eventually, we generate a more comprehensive conceptual design or user interface mock-up.
The search page contains an input field and search button, and transitions to the result page. Course is a way of displaying the result.
From this mock up, we recognize many connections.
- For example, for the search page to fulfill its responsibility to search, it needs, Input Field, Search button, and Results Page.
- This also translates to Search Page having connections to Input Field, Search button, and Results Page.
From a conceptual design, we move to making a technical design where, just like building design, you try to add a detail how those components, connections and responsibilities can be implemented.
For example, we refine each component until it is specific enough to be designed in detail.
For example, how does the search page fulfill its responsibility of searching a list of courses for relevant ones, given that a user has entered a keyword? Does the page need to talk to an external system?
Suppose the university already has a Course Database component which your course Search Page can connect to. Since Search Page requires Course Database in order to fulfill its responsibility of search, a connection exists between Search Page and Course Database.
Here, we can’t really use a conceptual user interface mockup, since we are now designing internal software components.
Later on in the specialization, you will learn about different technical diagrams that describe the structure and behavior of these components.
Components, when they are refined enough, turn into collections of functions, classes or other components.
These pieces then represent a much simpler problem that the developers can individually implement.
You can easily imagine that larger systems require more design time. With large systems, there are also more components, connections and responsibilities to keep track of. And since these components themselves will be big, they will be refined to many more components before the design can be detailed.
You now have learned to take some time to think about the problem and outline the conceptual and technical design before actually implementing the solution.
Design artifacts, like conceptual mock-ups, help to clarify design decisions with clients and users.
Technical diagrams help to coordinate development work.
CSM, CSPO, CSD, CSP-SM, CSP-PO (ScrumAlliance.org)
Certification Profile Link-
Currently working as Lead Team (Application Architecture) at Raven Systems Ltd. Passion for software development especially agile practices such as TDD with in depth knowledge of Object Oriented Programming, SOLID Principles, Gang of Four Design Patterns, Some Enterprise Application Architectural Patterns. Over 8 years of software development experience ASP.NET. Has the ability to understand and transform complex business requirements into software ensuring applications are delivered on time. Also experience in non Microsoft .NET technologies such as Dapper.Net, Git, Structure Map & Angular, Bootstrap, HTML-5, CSS-3 etc.