What is the point of having requirements if the designs are not made according to them?
Where is the traceability between requirements and design? (I've never seen requirements called out in a design. Most times I don't think the developer even refers to them, only to the mental model in their head. It's a chore, not a useful process.)
When stakeholders read requirements and nod their approval, usually what they're saying is, "I tried to read this, but it confused me, and I don't know what this means. Now of course I'm not going to say that, because I'm not going to look stupid, but I hope you understood what I want." Or, "I didn't read this, because I don't want to, or I don't have time, but you seem intelligent to me, and I trust you know what you're doing." How could requirements be written so that users would actually read them? (The same could be said for a lot of documentation.) Is there any point to producing documentation that doesn't get read? (CYA doesn't count.)
I guess you get anxious ... and we all know what that’s like. But I think that “ yakhal ” (Hebrew) or " elpis " (Greek) does not preclude the possibility of action - whether it’s writing about the situation, or something more (and don't underestimate the power of journaling!) Indeed, you don't think of prophets or apostles as the kind of people to sit around just waiting for something to happen. They act, but their action is tempered by the realization that things don’t look too good at the moment (otherwise why would the issue even be coming up?) So they act and wait at the same time, knowing that the fruits of their action are ultimately dependent on the Lord. And of course the Lord is known to have us do things for a while before any kind of clear result is made known. Like planting, and then watering, and then waiting, for a seed to turn into a plant. Farmers probably understand waiting a lot better than we do. They think in seasons and years, not months or we...
Comments