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.
This may be true in the virtualised reality of pure software development, but I cannot see any realistic mechanism for this to work where the physical world is involved. For example, PCB design. There are certain constraints and rules that must be defined before the design can commence. Constraints that can't really be changed significantly during development without compromising all prior work.
You may argue that this is nothing to do with software development, but I develop firmware. This is often closely associated with the underlying hardware and is difficult to change in the event the starting principles are updated. In the same way that the foundations for a two bedroom bungalow are unlikely to be interchangeable with those needed for a multi-story carpark despite being identical abstractions.
I would be interested to hear if there is a better mechanism to address these issues using your approach. Perhaps you can direct me to an article that discusses such an approach.
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.