Quick takes: Requirements
The whole notion of a requirement is nonsensical if you're working with agility. It's a creature of waterfall big-up-front thinking. Even so called non-functional requirements are better thought of as system characteristics, what Neal Ford and Mark Richards call "-ilities" (because many of them, e.g. scalability, end in -ility), I think. Those characteristics do need to be identified early, and pervade all development. You cannot add in security or quality after the fact. There is no "story" that says "make it secure." That would require rewriting the entire application. The other things that people think of as "requirements" have no real place in agile working. We solidify those details as we work, and change them based on feedback. There's nothing "required" about them.
When you have a team working on a payment processor, or an app focused on wealth management, it's true that the development team may or may not have experience in these areas, and it's not easy to establish everything from the beginning based solely on experience.
However, I agree with Allen that we can discover from the start and establish some guidelines or principles according to the area.
I can think of something to start with like:
------
Key Development Guidelines
1. Security-First
- Encrypt all sensitive data at rest and in transit.
- Implement PCI DSS compliance, strong authentication, and regular security audits.
2. Payment Ecosystem
- Support various payment actors (IRS, Mastercard, VISA, AMEX).
- Handle batch, near-real-time, and real-time processing reliably.
3. Data Management
- Ensure all entities (Merchant, Card, Transaction, etc.) are trackable.
- Build a data model for efficient reporting and compliance with regulations.
4. Scalability & Performance
- Design for high transaction volumes with scalable architecture.
- Combine monolithic core with microservices for flexibility.
5. Agile & Continuous Delivery
- Adopt Agile practices, with CI/CD pipelines for fast, secure releases.
6. Collaboration
- Ensure strong cross-functional teamwork with shared documentation and clear communication.
7. Compliance & Monitoring
- Enable audit-ready logging, meet regulatory standards, and set up robust monitoring from day one.
------
I've never done it, but I'd like to do something like this. It's a mini team Manifesto for that specific product. It can change, reflects some assumptions, allows us to start talking about important issues from the beginning.
I know requirement is the no-no word ;) But, I think this sometimes ignores certain company or geographic cultural aspects. I sometimes work with teams that, if things would not be formalized, almost nothing productive would happen. It even goes so far that it almost feels like a complete reset from one day to the next, making it seem as though yesterday's discussions never happened. Do you have any angle on this on how not using requirements would be better?