I've recently been assigned to work on a small project which is being implemented in Haskell. Coming from an OO/imperative background, I'm used to converting requirements/user-stories into use-cases and sequence diagram prior to coding.

However, the Haskell project that I have been assigned to, the team prefers to transform the user requirements into predicate logic proposition/statements. I was aware of logic being used in safety critical systems and formal methods for software engineering, but not so much in day to day programming. Is this common practice in the FP realm? Where can I learn more about this?

It seems like a natural way to 'model' the requirements and derive the 'functions' from the predicates along with writing down the necessary type specifications for the functions to operate on. But is that how it is done/recommended in practice or is it something peculiar to my team?

(I've tried searching extensively prior to asking this question here. Searching for "requirements specification in functional programming" (and different keyword synonyms and combinations) doesn't lead to anything meaningful.)


2 Answers 2


I will say that it's not limited to functional programming, it's more related to the goal of the project. By using predicate logic (higher order logic) you can create prove for the logic used in the requirement. Translating the logic into functional languages is probably easier. It's also possible to then translate the proven functional language implementation into procedural languages to get some kind of proven way of implementing it.

If we can prove the program then we don't need to test it. Even if a program passed 1000 tests, it's still not proven. Obviously, it's not easy to create the proofs so we just create tests instead.

You might also want to search for theorem prover, isabelle/hol.


That's one way to deal with functional programming. It tends to fall out from the flowcharts and data flow diagrams of the "old days." Instead of thinking in terms of objects, functional programming tends to focus on what actions need to be performed. The data becomes incidental, bits of fluff to carry along to hold on to what you're trying to do.

  • this reads more like a comment, see How to Answer
    – gnat
    Jun 9, 2015 at 21:12
  • 2
    Sorry. One person's comment is another person's answer. This isn't my first Stack Exchange rodeo.
    – Joe Sewell
    Jun 9, 2015 at 21:18
  • Not sure I agree. The question itself is going to gather opinions so maybe there are problems with the question but the answer I believe actually addresses the question asked. Flowcharts and data flows are an important part of business requirement specifications.
    – maple_shaft
    Jun 10, 2015 at 2:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.