Blog

  • How to Validate a Software Specification

    How to Validate a Software Specification

    Interview Refresher

    Are we building the right product? Software specification defines the functionality of a system and the constraints under which it must operate. Requirements validation ensures that the specification is correct, consistent, complete, feasible, verifiable, and aligned with business and user needs.

    Validation is different from verification:

    • Validation asks: Are we building the right product?
    • Verification asks: Are we building the product right? [1]

    Both are essential, but validation comes first because it confirms that the defined system is actually the one stakeholders expect and that it is fit for purpose.

    Below are the core techniques for validation of requirements of technical specifications.


    1. Reviewer Check for Errors and Inconsistencies

    A reviewer or team of reviewers reads through the specification to identify:

    • Errors
    • Inconsistencies
    • Contradictions
    • Unclear sentences
    • Missing details

    This is often the quickest way to uncover obvious issues before deeper validation activities begin.


    2. Prototyping

    Prototyping involves building a simple working model or partial system to help customers and engineers clarify what the final system should do. It is particularly useful when requirements are unclear, complex, or high risk. Prototypes help stakeholders “see” the system and confirm whether the written requirements reflect their expectations.


    3. Generating Test Cases

    A powerful technique is to generate test cases directly from the specification. If a requirement cannot be tested then it is not written clearly enough.

    Test case generation helps identify:

    • Ambiguous or vague requirements
    • Missing conditions
    • Contradictory behaviours
    • Requirements that are not verifiable

    This technique links validation to quality assurance.


    4. Validity Checks

    Validity checks ensure that the requirements genuinely reflect business or stakeholder needs. A specification may be formally correct yet still include requirements that do not contribute to the real objectives of the system. During validity checks, we ask:

    • Does this requirement belong in the system?
    • Does it support a real user or business need?

    5. Consistency Checks

    Consistency checks ensure that requirements do not contradict each other.
    Examples include:

    • Conflicting business rules.
    • Two requirements defining different behaviours for the same scenario.
    • Contradictions between functional and non-functional constraints.

    A consistent specification avoids logical conflicts that could derail design or testing later.


    6. Completeness Checks

    Completeness checks ensure that nothing important is missing from the specification.
    This includes verifying that:

    • All inputs and outputs are defined
    • All scenarios, constraints, and user types are considered
    • There are no “TBD” or “to be confirmed” placeholders
    • Non-functional requirements (performance, reliability, response time) are fully stated

    Incomplete specifications are one of the main causes of project delays and rework.


    7. Verifiability

    A verifiable requirement can be tested. If a requirement cannot be verified, it cannot be validated during testing or acceptance.

    Example of non-verifiable requirement:

    “The system should respond quickly.” This must be rewritten using measurable criteria.


    8. Realistic or Feasible Requirements

    Feasibility checks ensure the requirement can realistically be implemented. This includes checking:

    • Technical feasibility.
    • Cost and budget constraints.
    • Timeline constraints.
    • Existing system limitations.
    • Available skills and technologies.

    A requirement that cannot be achieved in practice is not a valid requirement.


    Summary

    By checking for validity, consistency, completeness, verifiability, and feasibility, errors and omissions can be identified early in the software development life cycle (SDLC) to improve overall project outcomes. If you need to perform detailed and thorough work there is an IEEE Standard, “IEEE Standard for System, Software, and Hardware Verification and Validation[2]

    Footnotes

    [1]Ian Sommerville, Software Engineering, 10th edition, Pearson, 2016, p. 14.
    <[2] IEEE Standard 1012-2024, Standard for System, Software, and Hardware Verification and Validation. Available at: https://ieeexplore.ieee.org/document/11134780.

  • SOLID Coding Practices: An Interview Refresher

    SOLID Principles

    • S: Single Responsibility
    • O: Open/Closed
    • L: Liskov Substitution
    • I: Interface Segregation
    • D: Dependency Inversion

    This post provides a concise summary of each principle with C# examples here and at https://github.com/dotnetdiva/SOLID to refresh your memory before technical interviews or design discussions.

    Software design principles assist developers to write systems that are modular, scalable, and easier to maintain. Among the most widely recognised are the SOLID principles, a set of five guidelines introduced by Robert C. Martin to promote high-quality object-oriented design.

    For interview preparation, understand each principle’s intent and be able to discuss an example of implementation. The expected output is shown in GitHub for the code samples, but the key to understanding is to walk through the code and see how it applies to each principle.


    1. Single Responsibility Principle (SRP)

    Definition

    A class should have only one reason to change, meaning it should perform a single, well-defined task.

    Example

    Consider a class that processes user data and writes it to a file. These are two distinct responsibilities. A better approach is to separate them:

    public class UserDataProcessor
    {
        public void Process(User user)
        {
            // logic
        }
    }
    
    public class FileWriter
    {
        public void SaveToFile(string data)
        {
            // logic
        }
    }

    Why it matters

    This separation improves maintainability and reduces the likelihood of introducing unintended side effects when modifications occur.


    2. Open/Closed Principle (OCP)

    Definition

    Software entities should be open for extension but closed for modification.

    Example

    Instead of modifying an existing class to add new behaviour, use inheritance or composition to extend functionality:

    public interface IShape
    {
        double Area();
    }
    
    public class Rectangle : IShape
    {
        public double Width { get; set; }
        public double Height { get; set; }
        public double Area() => Width * Height;
    }
    
    public class Circle : IShape
    {
        public double Radius { get; set; }
        public double Area() => Math.PI * Radius * Radius;
    }

    Why it matters

    This principle supports flexibility and reduces the risk of regression when new features are introduced.


    3. Liskov Substitution Principle (LSP)

    Definition

    Objects of a derived class should be substitutable for objects of the base class without affecting program correctness.

    This concept was introduced by Barbara Liskov and Jeannette Wing (1994), who defined behavioural subtyping as a requirement that subtypes preserve correctness. Robert C. Martin later incorporated this into SOLID to ensure that inheritance models support predictable substitution.

    Example

    A violation of LSP occurs when a subclass contradicts the expectations set by the base class:

    public class Bird
    {
        public virtual void Fly() => Console.WriteLine("Flying");
    }
    
    public class Penguin : Bird
    {
        public override void Fly() =>
            throw new NotSupportedException("Penguins cannot fly");
    }

    In this example, substituting a Penguin where a Bird is expected breaks behaviour. A better design might separate FlyingBird and NonFlyingBird abstractions.


    4. Interface Segregation Principle (ISP)

    Definition

    Clients should not be forced to depend on interfaces they do not use.

    Example

    Large, general-purpose interfaces should be divided into smaller, role-specific ones:

    
    public interface IPrinter
    {
        void Print();
    }
    
    public interface IScanner
    {
        void Scan();
    }

    Why it matters

    This principle promotes cleaner, more modular interfaces and prevents unnecessary dependencies between unrelated functionalities.


    5. Dependency Inversion Principle (DIP)

    Definition

    High-level modules should not depend on low-level modules. Both should depend on abstractions.

    Example

    A class should depend on an interface rather than a concrete implementation:

    
    public interface IMessageService
    {
        void Send(string message);
    }
    
    public class EmailService : IMessageService
    {
        public void Send(string message) =>
            Console.WriteLine($"Email: {message}");
    }
    
    public class Notification
    {
        private readonly IMessageService _service;
    
        public Notification(IMessageService service)
        {
            _service = service;
        }
    
        public void SendAlert(string message) =>
            _service.Send(message);
    }

    Why it matters

    This approach enhances testability, promotes loose coupling, and supports dependency injection — a core practice in modern software frameworks.


    Summary

    Understanding the SOLID principles strengthens your ability to design maintainable, scalable, and testable systems. During interviews, be prepared to:

    • Explain the intent of each principle
    • Provide a concise code example

    Sources

    1. Robert C. Martin, Design Principles and Design Patterns, Object Mentor (2000).
    2. Barbara Liskov & Jeannette Wing, A Behavioral Notion of Subtyping, ACM TOPLAS 16(6), 1811–1841 (1994). https://doi.org/10.1145/197320.197383

  • Getting the Bugs Out of Software – Saving Lives and Money with AI

    Getting the Bugs Out of Software – Saving Lives and Money with AI

    $2.41 trillion. That’s the estimate of the cost of poor software quality in the US for 2022. $607bn of that was just finding and fixing bugs. Imagine a world where even safety-critical software systems do not fail. By safety critical, I mean the systems that control airplanes and air traffic, 911 calls, and the power grid delivering gas and electricity supplies. All of these have disasters reported where a computer glitch was cited as the problem. Medical machines are controlled by software, from the heart rate monitor on watches, to the robot surgeon in the hospital. The Food and Drug Administration (FDA) has a whole database of recalled medical devices that include software issues as root cause.  Some of them are Class I which means there is “a reasonable chance” that the product will cause health problems or death1.

    Software engineers are constantly trying to improve how software is created at all stages of the process, not just coding. How can it be right the first time? It is not possible to prove that there are no bugs. But engineers work hard to find them at all stages of creating and testing the software.  Once it is released, engineers still have to maintain the code and fix the issues that inevitably show up. Now I’m sure you’ve heard about Artificial Intelligence (AI), ChatGPT, machine learning, and big data. My research involved looking for ways to use those machine learning algorithms to find bugs.  I experimented to see if certain models can work together to make one stronger model, something like a voting system for best one. The data I used to feed into the machine to predict where the errors are, was created by NASA and is freely available for the purpose of improving software engineering.

    High power electricity poles in urban area connected to smart grid. ChatGPT.

    So, if software engineers can use AI to predict and find more of the errors while building and testing software, they won’t have to go back and fix things. That time can be used instead to innovate and create better new products and services. If they can find the problems in software that is already out there before safety-critical systems go down, it will save not only billions of dollars, but save lives.

    This post is adapted from my 3MT2 (three-minute thesis) entry November 2023 at East Carolina University.

    1. https://www.fda.gov/medical-devices/medical-device-safety/medical-device-recalls. Medical device recalls, U.S. Food & Drug Administration accessed 1/14/2025.
    2. https://threeminutethesis.uq.edu.au/higher-degrees-researchstart-your-3mt-journey-here. “The competition supports their capacity to effectively explain their research in three minutes, in a language appropriate to a non-specialist audience.”

  • Software Engineers

    Software Engineers

    Read/sing to the beat of Gary Numan’s Engineers
    The Pleasure Principle debuted at number one September 1979. Beggars Banquet Music Ltd.

    All that we are
    Is all that we need to be
    All that we know
    Is code and machinery
    Software engineers

    We are your Heartbleed
    we are your synth life
    we are your ‘help-line’
    We keep you online, For now
    Software engineers

    Cortana’s your voice
    Logic your blood flow
    AI’s your eyes
    We’re all you need to know
    Software engineers

    All that we are
    Is all that you’d love to be
    All that we know
    Is code and machinery
    Software engineers

    Footnote – Heartbleed was a vulnerability in OpenSSL https://www.cisa.gov/news-events/alerts/2014/04/08/openssl-heartbleed-vulnerability-cve-2014-0160

  • ecahill is a secure web site

    green lock icon
    Secure https

    Google’s move to mark http sites as “not secure” prompted me to activate an SSL certificate a few weeks ago. In October 2018, Google will show a red not secure* warning on HTTP pages that ask users to enter data.

    Hitchhikers Guide to the Galaxy author Douglas Adams
    Photo by Daily Mirror/Mirrorpix/Mirrorpix via Getty Images

    No need to panic, free certificates are available through Let’s Encrypt  to enable HTTPS.  Let’s Encrypt, @letsencrypt,  are a certificate authority (CA) that provide trusted certificates for free in order to implement best practices for TLS, transport layer security. NB: people may still use the term SSL, secure socket layers, even though they have upgraded to TLS.

    Geeks can try  Let’s Encrypt How It Works to understand the details .

    marking HTTP as “not secure” accessed 8/31/2018.

     

     

  • CodeStock 2016

    CodeStock schedule:
    I’m scheduled for Saturday 9:00am – 10:10am.

    Sat. 9AM Room 301D
    CodeStock 2016

    Attend the keynote at 9AM Friday to get your weekend off on the right foot.
    Say “Hi” if you see me at other sessions, such as @sfradkin “Live Coding Music: A Creativity Break for Your Programming Soul”
    or @JamesBender “How I Learned to Love Dependency Injection”.

    Mark A. Wilson @DeveloperInfra will bring you up-to-date on “Authentication Using OpenID Connect and OAuth 2.0”

    If game design is your thing, go see @ViNull.

    @pcameronpresley has two sessions on SOLID and testing that look extremely useful.

    codestock

  • That’s Agile

    True story

    Posted to my original site circa May 2014

    This week in a business requirements session, a product owner sighed, “If only we could break it down and see one piece working before we start on the next piece. Could we do that?”

    “That’s Agile!” I said, he looked at the business analyst as if to say “is she having a laugh?”, but she confirmed that it is a valid methodology, and she had worked with programmers applying it on other projects.  The timing was perfect because, yes, I would love to do that, and I was even registered for the TriAgile conference two days later.