Software Engineering Planning
During the process of defining the functional requirements, there are three pitfalls to watch out for. Are the requirements realistic? Are they consistent? Are they complete?
By Reid Phillips, Senior Software Engineer
You have an idea for a piece of software. What comes next? The first stage of Software Engineering is typically that of planning. The planning stage starts with your problem statement but quickly expands beyond the initial description, eventually providing a complete picture as derived from multiple perspectives.
First, a warning. Communication is a critical component of any software project. The problem is that communication is difficult. Pick a movie, comedy or tragedy, and quite often you will notice that the plot is predicated on some form of miscommunication: misunderstanding, misinterpretation, mishearing, etc. Software Engineering is just as susceptible to the shortcomings of miscommunication as is any other human interaction. The process of taking the idea in one person’s mind and transplanting it into someone else’s without any loss is problematic, at best. Our best bet is to understand communication is a key in the process and attempt to minimize any potential pitfalls.
Planning is all about communication. Initial meetings can involve the various members getting to know each other and the development team understanding the context of the problem being solved. The latter point should not be underestimated. Even if a development team has experience in the problem domain, which may not always be true, regardless it is quite common that clients bring to the table new terminology and new insights specific to their context. Because of this, it is important for clients and developers alike to be on the lookout for these ambiguous terms. Compiling a dictionary of terms for use during the project is a common solution.
As meetings progress and rapport continues to improve among the various team members, communication will also improve. This is one reason the Agile Manifesto encourages regular interactions between customers and a development team. Moving beyond the initial problem statement, the team will begin to define various functional requirements. Functional requirements are expectations of functionality to be provided by the system. These are primarily derived from the client’s assumptions about the system, but the entire team will be involved in assembling them.
Because the software project under discussion likely entails implementing new processes, modifying existing processes, or both, it is helpful at this point to understand and to be able to talk about the client’s organizational processes. One popular means by which to communicate the requirements of a software system are user stories. Typically, a user story is three parts: a user or role, description of business functionality, and explanation of context or justification. You may see different terms used to describe the three parts of a user story, but the idea is mostly the same. The user in a user story could be anything from a real person, to a category of people (e.g., men aged 35-45 with basic technology experience such as social media), to a company position (e.g., cashier or shift manager), to another software system, etc. The business functionality describes the feature to be implemented, such as a task to be performed by the user against the system. The context, or justification, provides meaning or rationale for the functionality to help the team better understand the story.
There are other common approaches used to assist with understanding organizational processes. Scenarios for the use of the desired solution may provide more detail than user stories and specific use cases can also provide a slightly different perspective. These methods all serve to identify actors and associated actions within the context of the software system.
During the process of defining the functional requirements, there are three pitfalls to watch out for. Are the requirements realistic? Are they consistent? Are they complete? Realism deals with hard constraints on a system. When first mulling an idea in our excitement it is easy to abstract away difficulties. What these hard constraints may entail will vary depending on the project, but a few examples might be similar to the following. It is not uncommon to expect our mobile devices to perform as well as a desktop computer when the reality is the processing capabilities of a desktop computer are much greater than that of a mobile device. While it might be possible to get around this particular issue, to do so often introduces additional complexities. Another possibility is that of payment middleware: software that facilitates communication between a point of sale system and a payment processor. Often times there will be very real constraints regarding what payment middleware can do based on the functionality provided by the point of sale and the payment processor.
Inconsistent requirements will often come about due to differing needs of various stakeholders in a software project. Among other reasons, these conflicting requirements could be caused by users or roles of the implemented system or juxtaposed positions of the clients regarding what the software should do. A resolution will often require some sort of compromise.
Complete requirements are difficult even for those with significant experience with building software systems. Quite simply, humans are not omniscient. This is one of the reasons for the iterative approach to development in the evolutionary methodologies where requirements can be re-evaluated on a semi-regular basis.
These ideas are not all that goes into a planning stage, but hopefully, they paint a better picture of what is involved in the early stages of Software Engineering. While every software project will look different in some ways these ideas are some of the more common features and pitfalls to expect. Converting an idea for software into a reality is difficult, but the planning stage of Software Engineering will help us set the stage for a successful implementation.
If you have an interest in custom software development for your point of sale environment, contact our New West Technologies sales team to discuss how our software engineers can make your idea a reality.
Related Article: Introduction to Software Engineering
***
Reid Phillips has a Ph.D. in Computer Science from the University of Arkansas and along with being a Senior Software Engineer, teaches Software Engineering as an adjunct professor, passing his knowledge on to the next generation. Reid also enjoys playing volleyball during his off time.
