1

I'm taking an Introduction to Agile Software Development course, The instructor was discussing an example about online store and asked us to write the User Stories and the Conditions of satisfactions and one story was As a user I can commit for marketing card that was selected previously in order to buy my goods, the conditions of satisfactions in this case contained some conditions in addition to The system must secure the Credit Card data across the internet connection using https

  • I disagreed with that and said this is a thing that must be done, not just in case the user asked me to protect it, and it is a fatal threat like or more important than SQl Injections and this is a non-functional requirement at the technical level and if the user mention it or didn't this must be taken in our development, some project managers in the course showed their disagreement and said this is a time wast on features that the user didn't ask for!, the instructor didn't give my comment any attention and didn't reply to me.

I really think I'm true and not convinced, but all of those trained people disagreed with me[I'm new in the software engineering field but used always to work as a developer], so I'm asking you about this.

|improve this question
  • I'm not clear here: You're saying your instructor says that you're supposed to secure the payment data as part of fulfilling user requirements and you disagree that it's not part of the user's requirements? – kolossus Dec 2 '13 at 21:39
  • 6
    Securing credit card data is a requirement from the credit card companies. pcisecuritystandards.org/documents/pci_dss_v2.pdf (Section 4.1) - how they are described in agile terms (as a user, as a customer, as a whatever...) dunno. But it is a requirement, and should likely be a requirement from your business owner as part of their relationship with the vendor. – user40980 Dec 2 '13 at 21:49
  • 1
    @MatthewFlynn that is valid for the US, though internationally it has much less impact. PCI, as a collection of multinational institutions has a bit more applicability in other countries (the OP's profile says Egypt). The US can't enforce laws there, but Visa can enforce its contracts with businesses or change its overhead rates when they fail to pass the checklist. – user40980 Dec 2 '13 at 22:02
  • 1
    @Ahmedsafan - In that case, it depends on who the customer is. You're right insofar as it's a technical requirement, but if the customer is not an end user but a technical one, they're in the position to require things like PCI-DSS/DA compliance. This will now include the data protection specifications. You're also mixing issues here: first there's talk of securing payment data, then talk of injection; two related but separate concerns. Protecting payment data and protecting system integrity are related, but the customer is (probably) in a position to tell you how to do only one – kolossus Dec 2 '13 at 22:06
  • 6
    PCI does not depend on US law. It is a legal contract between the credit card companies and whoever wants to accept credit cards. Thus, it works world wide. The contract gives PCI certain rights to examine your IT systems and procedures in case of an incident. They can even shut down the IT systems for investigation (remember Sony hack? 3 weeks downtime). – Andreas Huppert Dec 2 '13 at 22:19
7

You bring up an interesting point, as I don't see that many requirements documents would contain things like:

  • The application shall be free of SQL Injection vulnerabilities, or
  • The application shall be free of CSRF vulnerabilities,

as such a list might actually be (more or less) unbounded, and securing credit card numbers with HTTPS is an implementation detail.

That said, the requirement probably does exist somewhere, even if it's in the form:

  • The application shall secure credit cards in a manner acceptable to the credit card companies.

It's a real, testable requirement, and needs to be documented somewhere. It's not an implied requirement, any more than "The application shall use best practices while coding" is an implied requirement, even though it is a good idea.

|improve this answer
  • You often have non-functional requirements in specs, things like "must respond within 2 seconds" is quite common. Similarly "apply best practice in securing sensitive data" (or words to that effect) is another. – gbjbaanb Dec 2 '13 at 22:57
  • 4
    "Apply best practice in securing sensitive data" is not a testable requirement. – Robert Harvey♦ Dec 2 '13 at 22:57
  • "....manner acceptable to the credit card....." means this is not a requirement, unless there references elsewhere to define what this means. If there are references elsewhere, refer to them and make this a real requirement. Test: would you commit to meeting this requirement on a fixed price contract? – mattnz Dec 3 '13 at 0:33
2

Yes, this is clearly a requirement for any modern website to do business. Is it from the customer? Maybe, maybe not. Customers surely want you to prevent their credit card data from being stolen, but there are certainly user stories used to represent technical debt and other infrastructure necessities like this.

Also I hate to see how the credit card data is secured as part of the user story (that's an implementation detail best left to the technical experts), but that's relatively minor in this case.

|improve this answer
1

An implicit requirement might be

You shall not hit my car when I am driving

Of course this goes without saying universally but is it a requirement at all? I would argue that it is not. Since the nature of this specific statement is a universal truth, and the fact that in the skillset of driving this is expected as a requirement of a good driver.

The language certainly sounds like it could be a requirement but it is not a requirement in my opinion. Any programmer or software developer should be conscious of security issues in their code just as a driver should naturally avoid accidents.

Programmers still from time to time write insecure code that puts users credit card information at risk, just as drivers occasionally get into accidents. I view security flaws as an "accident" or "incompetence" or both. Their are few hard and fast standards when it comes to software development and credit card security is one where there should be no debate in how user stories and features involving credit cards should be approached regardless of language platform, framework and design.

In summation, development of proper security with credit cards should be factored into a developer's estimates as an understood and known anticipation of technical work required to eventually achieve the user story or requirement.

|improve this answer
  • I like this answer also, this is nice but how to say this is the best answer or another answer, from the start of the agile course the instructors always say "I think", "this is valid but I don't like it", "yes this can be in our category".....etc they are too flexible I can't make a solid background, I'm a c++ developer between many software engineers and project managers, in agile how to say this is true and this false? – ahmedsafan86 Dec 3 '13 at 19:36
  • 1
    @Ahmedsafan It is ironic that the instructors are so flexible because the main goal of Agile is to be flexible. Remember the Agile Manifesto, Individuals and Interactions over Processes and Tools. There are no defined rules and no true and false. Instead interact with your instructors, customers and users and find out what makes the most sense for your situation. – maple_shaft♦ Dec 3 '13 at 21:59
  • Well the Highway Patrol or equivalent is a Stakeholder (and hopefully not an Actor) in the car scenario. You have a (non functional) requirement to "Comply with all local traffic regulations". – James Anderson Dec 4 '13 at 1:25
  • @JamesAnderson Complying with all local traffic regulations should be expected by the stakeholder which is why I don't like that as a non-functional requirement. Instead if cars were on a special race track void of local traffic laws then I would specify the exceptional rules as a non-functional requirement. This is just my preference. By defining a given thing as a non-functional requirement you teach developers learned helplessness. In the future when they do not see best practices lined up as individual requirements then they won't perform that necessary work. – maple_shaft♦ Dec 4 '13 at 13:28
1

I think you are correct.

The Credit Card issuer/authorizer is an Actor in this senario. You absolutly need to secure/encrypt the customers data or you will be cut off from the payments system and stuck with paypal and postal orders.

In a similar situation you do not deduct sales tax because the user and the customer request it, but because the State absolutely requires you to do so. In this case the State tax collection agency should be explicitly defined as an Actor/Stakeholder with there own set of requirements and conditions.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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